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citations Dl, D2. Claims 22, 23 lack novelty in Ught of Dl (see for example Figures 2, 3, 4 and 5). 
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claims 22, 23 lack an inventive step in the light of D 1 . 
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of examination. 
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(54) Title: METHOD AND APPARATUS FOR CONTROLLING COMMUNICATIONS 
(57) Abstract 

The present invention relates 
generally to a method and apparatus 
for preparing and processing informa- 
tion to be sent or received via a net- 
work, or communicated to or from 
other data carriers such as smart cards. 
Tht present invention describes the 
construction of a novel "virtual ma- 
chine" which can be implemented on 
a device having a minimal amount of 
hardware, such as hardware which is 
used for processing payment transac- 
tions (EFTPOS and the like). Prior art 
virtual machines tend to slow down 
operation of the device, as they are 
effectively acting as an interface be- 
tween an applications program and 
the actual device drivers. This is a 
problem. The virtual machine of the 
device of the present invention in- 
corporates a virtual message process- 
ing means, which is arranged to con- 
struct, deconstruct and compare mes- 
sages and which is applied in the na- 
tive code of the processor. The mes- 
sage instruction means are provided in 
the application to direct and control 
the message processor. Similarly, a 
protocol processor means is provided 
in the virtual machine for governing and organising 
The provision of these elements increases the speed 
for use in communications, able to be implemented 
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communications, under the direction of a protocol instruction means in the application, 
and efficiency of the virtual machine and allows implementation of a practical device 
on different hardware having different BIOS/OS. 
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METHOD AND APPARATUS FOR CONTROLLING COMMUNICATIONS 

From a first, general aspect, the present invention 
relates to a method and apparatus for preparing and 
processing information to be sent or received via a network. 
A network in this instance may be implemented as data 
carried either over communications lines and/or stored on 
smart cards (or other data carriers) and physically 
transported. 

From a second, more specific aspect, the present 
invention relates to a method and apparatus for controlling 
remote payment transactions, particularly, but not 
exclusively, for controlling remote payment transactions 
where a persons account is credited and/or debited from a 
remote location in exchange for goods/services cash or 
credit, or where account information is accessed remotely to 
enable approval of a transaction. 

Devices for carrying out remote payment transactions 
are well-known. These "payment terminals" include EFTPOS, 
credit card payment terminals, etc. 

The most common function of payment terminals is to 
remotely access a persons account information and either 
carry out a transaction, such as crediting or debiting the 
account, or, particularly in the case of credit card payment 
terminals, to check the users account to ensure that there 
are sufficient funds to cover a transac-tion . Note that 
although credit card terminals do not necessa-rily remotely 
credit or debit the users account (the credit/debit 
transaction usually being carried out by a separate paper 
bill trail) and merely provide the information that the 
users account is sufficient to cover the transaction, such 
payment terminals still fall within the ambit of the present 
invention and the term "transaction" as used herein includes 
the operation of remotely checking the users account to "ok" 
a transac-tion. 

A payment terminal may, for example, provide for the 
following basic operations: 
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(1) Input of information which is required to enable 
access to a customers account. The information is most 
often read from a magnetic stripe on a credit card or bank 
card or the like, or a smart card. In addition to reading 

5 details from a card a personal identification number (PIN) 
or the like code may also be required. 

(2) Obtain access to the customers account. This is 
usually done by remote communication with a processing 
device holding the person's account data, usually on bank. 

10 premises and remote from the payment terminal. Usually, 
information on the customers account input to the payment 
terminal will need to be transmitted for verif ica- tion and 
to enable access to the account. Also a money amount will 
usually need to be input to the payment terminal and 

15 transmitted over the communications line. At least some and 
perhaps all of the transmitted data may be encrypted for 
security purposes and the payment termi-nal is therefore, in 
such a case, required to have means (3) providing 
encryption. 

20 (4) The payment terminal may need to be able to 

receive communications over the remote line from the 
processor accessing the customers account, ie. to provide an 
"answer" to the payment device regarding the user 
transaction. The answer may include information that an 

25 account debit/credit has taken place (eg. EFTPOS) or merely 
an approval that the customer has enough money in his 
account to enable a transaction (some credit card payment 
terminals) . Again, this transmitted information may be 
encrypted and, if so, will require translation (5) in the 

30 payment terminal. 

(6) To provide an indication that the transaction 
request is approved or that a transaction has occurred, by 
display or printer, for example. Displays may also be 
required to prompt an operator or customer to input 

35 information, e.g., input your PIN "Input Amount". 

There are many different brands of payment terminal. 
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utilising many different software and hardware arrangements. 
This gives rise to a number of problems. 

Any account acquirer (eg. bank) will generally have 
their own operating requirements as to how remote payment 
5 trans-actions will be handled. The account acquirer may 
purchase a series of payment terminals which have been 
configured by a manufacturer to the acquirer's require- 
ments. These payment terminals will then be licensed or 
rented or more often supplied at no charge to merchants 

10 (e.g./ retail stores, garages, restaurants)- Multiple 
account acquirers may require access to their customers 
accounts via a single payment terminal. That is, one 
particular merchant may operate payment terminals which 
provide access to customers accounts at other account 

15 acquirers (e.g., other banks). Because of different 

requirements of different acquirers for handling of remote 
payment transac-tions, the payment terminal must be arranged 
to operate to satisfy the different require-ments . 

The terminal owner (often a principle acquirer) will 

20 have the terminal appropriate-ly arranged and programmed by 
the terminal manufacturer to satisfy the re-quirements of 
all account acquirers utilising the termi-nal. Payment 
terminals may need to contain several programs and select 
the appropriate program depending on the card to be 

25 processed or on an operator selection. 

It is often the case that the terminal owner may need 
to have the operation of the payment device amended to, for 
example, enable it to operate for an additional account 
acquirer, or to satisfy changed requirements for a 

30 particular account acquirer. Because of the different hard- 
ware/software architectures available, any operational 
alterations generally the require the input of the terminal 
supplier or manufacturer. The supplier/manufacturer will be 
required to reprogram the termi-nal or amend the hardware in 

35 order to carry out the alterations and they will. usually be 
the only person who has the appropriate knowledge. The 
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terminal owner is thus tied to the particular 
supplier/manuf actur-er of the par-ticu-lar brand of payment 
terminal . 

It is often the case that, the terminal owner may over 
5 time obtain different brands from dif-ferent manufacturers 
and for operational alterations may need to return the 
particular brand to each separate manufacturer. Over time, 
manufacturers may go out of business, in which case the 
payment terminals made by that particular manufacturer may 
10 be unsupported and any alteration may be difficult to 

achieve, or at least will require the input of a skilled 
person having detailed knowledge of the programming and/or 
hardware of the redun-dant manufacturer's devices. 



15 particular brand therefore causes cost, time and trouble 
when any operational alterations are required. There is 
therefore a reluctance to carry out operational alterations, 
which sometimes means that requirements of vari-ous account 
acquirers are not fully satisfied. When an oper-ational 

20 alteration does have to be carried out, it is costly. If a 
manufacturer goes out of business, the terminal owner may be 
left with nobody to alter the operation of his payment 
terminals, or indeed maintain the payment terminals. The 
present system is costly and inflexible. 

25 A payment terminal device usually includes a 

microprocessor and a number of peripheral units (e.g., card 

reader, display, printer, communications interface, etc) 

controlled by the processor. A payment terminal device 
usually comprises hardware, an operating system or a BIOS 

30 and is ready to accept an application for that arrangement. 
Or the device may be supplied with an interpreter to accept 
the applica-tions . 

To alter the operation of payment terminals, a new 
appli-cation must be created. This can be time consuming, 

35 costly and as the program-ming will be different for 
different types of devices, which may have different 



Being tied to a particular manufacturer for a 
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hardware arrangements as well, and must be carried out 
separately for each different type of device (i.e., 
different reprogramming operations must be carried out for 
different devices even where the same operational 
5 alterations may be required) . 

The programming alterations are not "portable" between 
different types of devices. 

The most time critical aspects of operation of a remote 
payment terminal involve the building up and break-ing down 

10 of "messages" and the formulation and operation of 

communications. By "messages" is meant, for example, 
information data which is required to be input to the device 
or communicated or displayed in order to enable carrying out 
of a remote payment transaction, and includes information to 

15 be communicated to the bank, e.g., customers card number, 
customers PIN, amount of transaction, etc; displayed 
information such as "Please Input Amount"; information to be 
read from a customers magnetic stripe card or smart card and 
manipulated by the device e.g., card nunober, expiry date, 

20 etc. The operation of payment termi-nals is greatly 
concerned with the collection, rearrange-ment and 
communication of this message data to enable a remote 
payment transaction . 

In conventional devices, each time a message is 

2 5 constructed or deconstructed, the operation of the machine 
will be handled by the application program. To change 
operation of the machine, the application must be changed. 
This is laborious, and gives rise to problems, as discussed 
above , 

30 The technique of creating a ^virtual processor^ (or in 

this case microprocessor) is well known and referred to as 
an interpreter. This allows programs to operate independent 
of processor. With the newer technique of also creating 
virtual peripherals then the whole is referred to as a 

35 "virtual machine" . 

A _virtual machine^ is computer programmed to emulate a 
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hypothetical computer* Different incompatible computers may 
be programmed to emulate the same hypotheti-cal computer. 
Any computer programmed to emulate the hypotheti-cal 
computer will thus be capable of executing programs for the 
5 virtual computer. This creates a complete portable 
environment for program operations, 

A problem with virtual machines is emulation is slower 
than normal program execution. For some applications this 
performance penalty is a significant problem. 

10 The above problems and disadvantages which have been 

discussed specifically in relation to devices configured to 
process payment transactions also would apply to devices 
configured to prepare and process any information to be sent 
or received via a network, not restricted to payment 

15 transaction information. 

From a first aspect the present invention pro-vides a 
device arranged to process messages for communications, 
comprising a virtual machine means including a message 
processor means which is ar-ranged to process messages 

2 0 communicated to and/or to be communicated from the device, 

and message processor instruction means, arranged to provide 
directions for operation of the message processor means. 

"Communicated" includes transport of data via a data 
carrier such as a smart card. 

25 The message processor means is preferably a program 

mod-ule the specif-ic function of which is to assem-ble, 
disassemble and corn-pare mes-sages. By mes-sages we mean a 
se-quence of data comprising usually a plu-rality of 
information fields to be com-muni-cated. 

30 The message processor means is preferably translated 

into the native code of the microprocessor in each hard-ware 
device on which the virtual machine is to be implemented. 
The message processor instructions are preferably virtual 
instruc-tions to be expressed only in the language defined 

35 by the message processor means- and thus never requiring 
trans-lation to any real hardware processor. 
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The message pro-cessor means in at least a pre-ferred 
embodiment provides two specif -ic advan-tages over con-ven- 
tional arrange-ments 

1) Faster Operation. The processor (executing as 
5 native code) operates at full micropro-cessor speed 

overcoming the problem of slow emulation speed for message 
related f unc-tions . 

2) Faster, simpler programming. The instructions for 
the message processor preferably consist of actual message 

10 "descrip-tions" . The programmer need only describe the 
message content, all data conversion, manipulation and 
processing is automati-cally performed based on the mes-sage 
descrip-tion , This is a more intuitive and compart-mental- 
ised approach which preferably leads to faster programming 

15 with less errors. 

The virtual machine preferably also includes a protocol 
processor means particularly arranged to organ-ise 
communications to and from the device, and also pre-ferably 
include protocol processor instructions which are arranged 

20 to provide directions for operation of the protocol 
processor means. 

The protocol processor means is preferably a 
program mod-ule the spe-cific function of which is to 
control and select the se-quence of message processor oper- 

25 ations in relation to mes-sages received and trans-mit-ted . 
The protocol processor means is preferably 
translat-ed into the native code of the micro-pro-ces-sor in 
each hard-ware device on which the virtual machine is to be 
implemented. The protocol proces-sor in-structions are 

30 virtual instructions ex-pressed only in the language defined 
by the protocol processor means- and thus never requiring 
trans-lation to any real hardware pro-cessor. The protocol 
processor means provides two specific advantages over 
conven-tional arrangements : 

35 1) Faster Operation. The processor (executing as 

native code) preferably operates at full micropro-cessor 
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speed overcoming the problem of slow emulation speed for 
proto-col related functions - 

2) Faster, simpler programming. The instructions for 
the protocol engine preferably consist of an actual diagram 
5 of the message flow. To change message flow or sequence, the 
programmer can modify an intuitive diagram, all multi- 
processing and other complica-tions are handled auto- 
matically. This more intuitive and compartmentalised 
approach leads to faster programming with less errors. 

10 In a preferred embodiment, therefore, a device in 

accordance with the present invention includes a virtual 
machine including virtual processors which are specifically 
arranged to control message construction, deconstruction, 
comparison and to control the communica-tion of information, 

15 both for reception from a network and transmission to a 

network. These operations can therefore be carried out at 
speed, overcoming the prob-lems with known virtual machines 
and interpreters, which tend to operate slower than 
conventionally programmed devices. The virtual machine 

20 therefore lends itself particularly to applications relating 
to communications, such as payment terminal devices and 
other devices in which message pro-cessing and communication 
comprise a significant proportion of the operation of the 
device. In payment terminals, for example, a payment 

25 terminal including a virtual machine having the message 

proces-sor means and protocol processor means can operate 
satisfactorily speedwise. The virtual machine can be 
implemented on any hardware, BIOS/OS arrangement and 
therefore fa-cilitates portability of programs. 

30 Implementation of such a virtual machine on pay-ment 

terminal devices of different brands enables operation of 
the payment terminal devices or brands to be altered merely 
by altering application commands generic to all brands. 
Each brand is seen by the appli-cation as the same virtual 

3 5 machine. 

The virtual machine preferably also includes a function 
SUBSTITUTE SHEET (RULE 26) 
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processor means arranged to control overall vir-tual machine 
action in response to operator or other external events, and 
also preferably includes function processor instruc-tions 
which are arranged to provide directions for operation of 
5 the function processor means. 

The function processor means is preferably a program 
mod-ule the spe-cific function of which is to control and 
select general op-er-ations of the device not specially con- 
trolled by the mes-sage and proto-col pro-cessor means. 

10 The function processor means is preferably translat-ed 

into the native code of the micro-pro-ces-sor in each hard- 
ware device on which the vir-tual machine is to be 
implemented. The function proces-sor in-structions are 
preferably virtual instruc-tions to be expressed only in the 

15 language defined by the function processor means- and thus 
never re-quiring trans-lation to any real hard-ware pro- 
cessor . 

In the preferred embodiment, the "applica-tion" 
will there-fore com-prise in-structions for the mes-sage, 
20 proto-col and func-tion pro-ces-sor means. The instruc- 
tions for the func-tion processor means may include such 
pri-or art modules as a function event schedular and func- 
tion selector . 

Although the present invention is particularly 
25 applicable to application in payment terminals, it is not 

limited to such applications. The invention can be applied 
in any device where advantages are likely to be achieved for 
the arrangement and control of communica-tions . 

With the advent of the Internet and other exten-sive 
30 communications networks, it is believed that the operation 
of computers, such as PC's, will become more and more 
oriented towards acting as "servers" and/or "brows-ers". In 
other words, a major function of PC's connected to a network 
will be to operate either as a server, provid-ing 
35 information and/or programs to the network for access by 
other parties, or as a "browser" for obtaining 
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information/programs available on the network and operating 
on them. It is likely, in fact, that PC's will be asked to 
operate as both a server and a browser. This operation will 
not merely be restricted to the Internet, but for any 

5 network, even Local Area Net-works. 

The applicant also believes that many other classes of 
devices may be connected to a network. For example in the 
future a home video cassette recording machine could be 
connected to the Internet (along with other devices) 

0 allowing remote programming from a browser device. An 

example of the use of this would be a worker upon learning 
of a requirement to stay at the office late and miss a 
favourite show could access their home VCR from the office 
and pro-gram it- 

5 Telephone calls will eventually be digital and most 

likely use the Internet as the digital network. Like the 
VCR, this does not mean all phones would need a qwerty 
keyboard and colour display. They will both represent other 
classes of Internet connected devices- not requir-ing the 

0 exact same configuration as PC's. 

The present invention facilitates the production of a 
small, economical device which is particularly ar-ranged to 
deal with communications, to build, compare and deconstruct 
message information. Such a device is novel maybe termed a 

5 Specialised Network Access Computer (SNAC) - The appli-cants 
believe that a SNAC could emerge as a class of device 
allowing data entry and control through the Internet where a 
smaller, more economical device than a conventional PC is 
appropriate. In a preferred embodi-ment, the device is 

0 implemented utilising a virtual machine having a message 

processor and a proto-col proces-sor as discussed above. In 
the preferred embodiment, the software of the device can be 
considered to include three layers of virtual machine 
software (the HW drive layer, the Hardware Abstraction 

15 Layer, and the Vir-tual Machine Processor layer), and a 

software applica-tion . All layers other than the Virtual 
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Machine Pro-cessor Layers are well established by prior art. 
A payment termi-nal can be used substantially without alter- 
ation as the hardware component of the device. A hardware 
abstraction layer (HAL) is a set of routines providing a 
5 common application program interface (API) to exercise the 
operating system, BIOS or hardware drivers. 

HAL consists of routines to either (a) implement the 
functionality not provided by the underlying operating 
system, BIOS or hardware drivers, but needed for the common 

10 API, and (b) translation of parameters and adjustments of 
functionality required to adapted underlining OS, BIOS 
routines for the routines specified by the common API, 

Such a SNAC can be applied in many different types of 
communication application over a network. 

15 The present invention also facilitates the production 

of devices which incorporate a snac as a functional element 
of the device. Such devices could include both devices 
collecting information for transmission over a network such 
a pay telephones, particularly those equipped with smart 

20 card facility, or devices receiving information from a 

network such as the futuristic VCR or even washing machine. 

Preferably, message instructions and protocol 
instructions may be developed on a convenient device such as 
a PC or general purpose computer, utilising a develop-ment 

25 tool in accordance with another aspect of the inven-tion. 

From a further aspect, the present invention provides a 
development tool for developing message in-structions for 
providing directions for operation of a message processor 
means to be implemented in a virtual machine as discussed 

30 above, the development tool compris-ing a processing 

apparatus arranged to receive data input by a user to build 
message instructions for the message processor means. 

The arrangement is preferably driven by a graphical 
user interface based program which provides various screens 

35 and fields for the user to input data relating to message 
instructions . 
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The message instructions are preferably subse-quently 
con-verted to code and downloaded into the device which is 
to employ them with the virtual machine. From a 

further aspect the present invention provides a development 
5 tool for developing protocol instructions for directing 

operation of a protocol pro-cessor means to be implemented 
with the virtual machine as discussed above, the development 
tool comprising processing means arranged to receive data 
input by a user to build protocol instructions. 

10 The arrangement is preferably a program which is 

arranged to build protocol instructions from the data input 
by the user. The program is preferably graphical user 
interface based and provides screens and fields to 
facilitate data input for the protocol instructions. 

15 Protocol instructions and message instructions can 

therefore be built on a PC and downloaded to device where 
the virtual machine is to be implemented. 

A tool has also preferably been provided for developing 
function processor instructions/ along the lines of the tool 

2 0 for the protocol processor instructions and message protocol 
instructions . 

Limited hardware provided by such a device as a payment 
terminal or other SNAC device does not lend itself to 
development and testing of applications programs. Although 

25 the final-ised application must run on the hardware, to 

devel-op and test an application it is more convenient to be 
able to utilise a more user-friendly device, such as a PC or 
general purpose computer. 

From a further aspect, the present invention provides a 

30 communications device including a virtual machine means 

including a protocol processor means arranged to organise 
communications to and from the device and protocol processor 
instruction means arranged to provide directions for 
operation of the protocol processor means. 

35 From a further aspect, the present invention provides 

means for emulating a virtual machine on a PC or other 
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general purpose computer, the virtual machine comprising a 
message processing means as discussed above. The virtual 
machine is arranged to operate on the PC or other general 
purpose computer so that instructions developed for the 
5 machine can be tested. 

Similar emulation is preferably provided for the 
protocol processor means. 

Emulation can therefore be used to test payment 
terminal or other SNAC application programs. 

10 The present invention further provides a method of 

operating a communications device, comprising the step of 
processing messages for communications by employing a 
virtual machine means including a message processor means 
processing messages for communication to and/or communis 

15 cated from a remote device, and message instruction means 

providing directions for operation of the message proces-sor 
means . 

The method preferably also includes the steps of 
processing communications by employing a protocol proces-sor 
20 means and protocol processor instructions providing 

directions for operation of the protocol processor means. 

Message processor means, message instructions, protocol 
processor means and protocol instructions are preferably as 
discussed above in relation to previous aspects of the 
25 invention. 

The present invention yet further provides a method of 
prograirauing a device for processing communica-tions, 
comprising the steps of loading a processing means of the 
device with a virtual machine means including a message 
30 processor means which is arranged to process messages 

communicated to and/or to be communicated from the device, 
and message processor instruction means arranged to provide 
directions for operation of the message pro-cessor means. 

The method of programming preferably also in-cludes the 
35 step of loading the processor means of the device with a 
protocol processor means arranged to organ-ise 
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communications to and from the device, and protocol 
processor instructions arranged to provide directions for 
operation of the protocol processor means. 

The present invention yet further provides a computer 
5 readable memory storing code for implementing a virtual 
machine comprising a message processor means arranged to 
process messages communicated to and/or from the device. 

From yet a further aspect the present invention 
provides a computer readable memory storing code for 
10 implementing message processor instruction means arranged to 
provide directions for operation of a message proces-sor in 
a virtual machine means, the message processor being 
arranged to process messages for communication to and/or 
from a device. 

15 From yet a further aspect the present invention 

provides a computer readable memory storing code for 
implementing the virtual machine including a protocol 
processor means arranged to organise communications to and 
from a device. 

2 0 From yet a further aspect the present invention 

provides a computer readable memory storing code for 
implementing protocol processor instructions arranged to 
provide directions for operation of a protocol processor 
means arranged to organise communications to and from a 

25 device. 

From yet a further aspect the present invention 
provides a specialised network access computer, including a 
micro processor and a virtual machine means, the virtual 
machine means including instructions for running on a 

30 virtual micro processor and an interface enabling the micro 
processor to operate the virtual processor. 

Preferably the specialised network access computer is a 
payment terminal or other type of "card computer" (being a 
computer which is arranged to process information from cards 

35 and/or communicate information to cards - cards being smart 
cards, magnetic cards or similar) , 
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The interface between the actual processor and the 

virtual processor preferably includes a hardware abstraction 

layer (AJL) or the like which provides a common API. 

Features and advantages of the present invention will 
5 become apparent from the following description of an 

embodiment thereof, by way of example only, with refer-ence 

to the accompanying drawings, in which: 

Figure 1 is a schematic block diagram of a payment 

terminal in accord-ance with an embodiment of the present 
10 inventions- 
Figure 2 is a schematic diagram of a control program 

architecture for the embodiment of figure 1; 

Figure 3 is a schematic flow diagram illustrat-ing 

device operation which requires the operation of the message 
15 engines- 
Figure 4 is a schematic flow diagram illustrat-ing an 

example of operation of the protocol engines- 
Figure 5 is a representation of a display (screen dump) 

available on a development tool for devel-oping a program 
20 for a device in accordance with an embodiment of the present 

invention, illustrating devel-opment of a message 

instruction for an example mes-sage; 

Figure 6 is a screen dump of a further develop-ment 

tool display illustrating further detail of develop-ment of 
25 a message instructions- 
Figure 7 is a further screen dump of a develop-ment 

tool display illustrating further detail of develop-ment of 

a message instructions- 
Figure 8 is a screen dump of a further develop-ment 
30 tool display illustrating development of a further message 

instruction. 

Figure 9 is a screen diomp of a further develop-ment 
tool display illustrating development of a protocol 
instruction; 

35 Figure 10 is a screen dump of a further develop-ment 

tool display illustrates further detail of develop-ment of a 
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protocol instructions- 
Figure 11 is a schematic diagram showing a struc-tural 
embodiment of the message instructions and description for 
the message processing means, and 
5 Figure 12A is a schematic diagram showing the structure 

of protocol instructions for an embodiment of the protocol 
processor means. 

Figure 12B is a representation of a display of a 
development tool for developing protocol instructions. 

10 An embodiment of the invention will now be described 

particularly with reference to a payment termi-nal device. 
The invention is not limited to payment terminal devices and 
the following description is given as an illustrative 
example only. The invention can be employed in all devices 

15 concerned with communications over a network, such as a 
Specialised Network Access Device. 

A payment terminal device in accordance with an 
embodiment of the present invention is illustrated in figure 
1, The device hardware comprises a processing means which, 

2 0 in this embodiment includes a central pro-cessing unit 1 and 
a memory 2 for storing instructions and data. The device 
further comprises a keyboard 3 for input; a card reader for 
inputting information from a card 5; a display 6; a printer 
7, and a communications interface 8 for communication with 

25 an account acquirer. 

Prior art devices generally have similar ar-range-ments 
to that illustrated in Figure 1. The number and type of 
peripherals to the CPU may vary, but the essential operation 
required by the prior art and the present inven-tion are 

30 similar. 

Such devices operate to facilitate remote pay-ment 
transactions, and a general overview of operation is as 
follows : 

(1) Information is taken from an account holder's 
35 (customer) card 5 via a card reader 4. Transac-tion 

information is input via the keyboard 3. The trans-ac-tion 
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information may include a money amount. The display 6 may 
prompt the user (merchant employee, custom-er) to input 
information (e.g., it may ask a merchant employee to input 
an amount) and may also display information as it is input. 
5 The keyboard 3 may also be used by the customer to input a 
code for the account, such as a PIN number, 

(2) The CPU communicates the information via 
communications interface 8 with an account acquirer com- 
puter. The account acquirer computer may carry out a 

10 transaction (e.g., deduct money from the customers ac-count 
and pay the merchants account) or may provide an ''authori- 
sation" that a transaction can be carried out. Information 
that an account transaction has taken place or that the 
account acquirer authorises a transaction to take place is 

15 transmitted to the communications interface 8 from the 

account acquirer computer. A display 6 may be provided to 
indicate that the transaction has occurred or may proceed. 

(3) When the transaction is complete, a print out of 
transaction information may be provided from printer 7. 

2 0 Prior art payment terminal devices are generally 

programmed in a conventional manner. That is, program-ming 
comprises a sequential set of operating instructions which 
are executed in sequence to carry out a remote payment 
transac-tion. This "sequential program" may be directly 

2 5 compiled onto the processor of the device so that the device 
is under direct program control or, as is more usual, an 
applications program in a conventional program-ming language 
may control operations through a BIOS/OS. Whatever 
conventional programming form is used, however, the device 

30 suffers from the problems which are discussed in the 

preamble of this specif ica-tion. The programs are not 
portable between devices having differ-ent hardware or 
operating system architectures and it is necessary to write 
a program specifically for each type of device- Further, 

35 any amendments to the operation of the device must be 

programmed by a programmer having knowledge of that par- 
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ticular device and program arrange-ment . 

Figure 2 is a schematic block diagram illustrat-ing 
architecture of a device in accordance with an em-bodiment 
of the present invention, 

5 The architecture comprises the hardware 100 the device, 

as illustrated and described in relation to figure 1. It 
also comprises the hardware drivers, known in the prior art, 
and including an existing BIOS/OS or hardware drivers, 
reference numeral 101 and also includes the Hardware 

0 Abstraction Layer Interface (HAL) 102. The HAL 102 and 

hardware drivers 101 form a layer of a virtual machine which 
also includes virtual machine processors 103. 

The virtual machine 101, 102, 103 is arranged to 
emulate a hypothetical payment terminal. Application 104 

5 controls the virtual machine 101, 102, 103 which in turn 

controls operation of the hardware 100. The virtual machine 
101, 102, 103 can be adapted for many different hardware 100 
arrangements (i.e. many different brands of payment 
terminal) . Different arrangements of hardware 100 can 

0 therefore be controlled by the same application software 
104. 

The provision of Hardware Abstraction Layers and 
hardware drivers for virtual machines is known in the prior 
art and fully described in various publications. Each 

5 peripheral of the virtual machine is defined to be able to 
act in some manner on a standard set of commands. The UKL 
implements the best interpretation of each command on the 
actual peripheral present. For example a printer is defined 
to implement a "feed paper ready for tear off" instruction. 

0 On differing roll paper printers this requires feeding a 
different number of lines, on tractor feed printers this 
requires feed to the next perforation. 

The virtual machine processors include a message 
processor 105 and a protocol processor 106, implemented in 

5 software code. The message processor is arranged to process 
messages communicated to or to be communicated from the 
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payment terminal via the communications inter-face 8. The 
protocol processor is arranged to organise communica-tions 
to and from the device, and to control and select the 
sequence of message processor operations in relation to 
5 messages received and transmitted. The message processor 
105 and protocol processor 106 are implemented in native 
code of the payment terminal and therefore operate at 
relatively high speed. Because much of the "work" of the 
payment terminal is in building, comparing and 

10 deconstructing messages and processing communications, the 
operation of the device is relatively quick even though 
employing a virtual machine, 101, 102, 103. 

The virtual machine processors 103 also comprise a 
function processor 107 the operation of which is to control 

15 and select general operations of the device not specially 

controlled by the message and protocol proces-sors 105, 106. 
The function processor is also preferably implemented in the 
native code of the micro-processor of the hardware 100. 

The application 104 includes protocol instruc-tions 

20 108, message instructions, 109, function support 110 and 

function instructions 111. The protocol instruc-tions 108 
govern operation of the protocol processor 106. The message 
instructions 109 provide directions for operation of the 
message processor 105. Function support 110 and function 

25 instructions 111 govern operation of the function processor 
107. The application 104 and virtual machine 101, 102, 103 
operate on data 112 input to the payment terminal to process 
it in accordance with the application 104. 

In this example, the application in-clude a set of 

30 "primitives" which are a series of symbol-ic commands which 
are executed by the device to control carry-ing out of a 
remote payment transaction. The appendix A to this 
specification lists primitives utilised by a pre-ferred 
embodi-ment of the invention and gives descrip-tions of 

35 their respective functions. It will be appreciat-ed, 

however, that a skilled person would be able to design their 
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own primitives for carrying out remote payment transactions 
and the invention should therefore not be considered limited 
to use of the primi-tives listed in the appendix. It is in 
fact anticipated that users of the system may desired to 
5 created their own primitives and product documentation 

attached includes instruction for this procedure should it 
be desired. 

Appendix A is in the form of a "HELP" file to be used 
with a product. The important information for the purpose 
10 of this description is the brief description of each 
"PRIMITIVE" and their function. 

The primitives operate utilising the data 112. The 
data 112 may be data being input to the device, such as the 
customers account nxamber/ information which is fixed 
15 (strings) in the device e.g., a particular account acquir- 
ers identity. 

The function processor 107 includes an event schedular 
and index as known in the prior art . In re-sponse to an 
event (e.g., swipe card) the event schedular operates via 

20 the index to look up a sequence of primi-tives 11 to be 
executed in response to that particular event. 

In the preferred embodiment, the virtual machine 
processors 103 are constructed using C and the applica-tion 
is constructed using C++ or Java. 

25 The device of this embodiment is event driven. When 

converting a device incorporation the SNAC hardware 
requirements to a SNAC by the provision of an appropriate 
HAL and virtual processors, and event driven structure can 
be added to a non-event driven underlying architecture 

30 through the HAL. This can be achieved through a software 
loop detecting events and generating an event call for any 
detected event. 

The application 104 responds to the occurrence of an 
event to dictate subsequent operation of the de-vice. For 

35 example, when a card is swiped through card reader 4, the 

appropri-ate sequence of instructions from the applica-tion 
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104 will be implemented. The event driven structure allows 
the hardware drives 101 to have control during idle periods. 
When an input event occurs the application is called to 
process the input and then returns control to the hardware 
5 drives 101, 

The application may be loaded on a remote payment 
terminal device with a pre-existing operating system. 
Where the operating system is event driven HW drivers 102 
can operate as an interface layer without any prob-lems. 

10 Where the pre-existing operat-ing system (HW drivers) is not 
event driven, amendments must be made via the HAL to convert 
to an event driven structure. 

Appendix B includes a description of a operation of the 
HAL 18 in accordance with an embodiment of the present 

15 inven-tion, on a functional level, A skilled person would 
be able to develop an appropriate HAL structure for an 
existing device or a new device. The appendix B is in the 
form of a "HELP" file for a product. It merely describes an 
example of implementation of a HAL and adaptation of an 

20 existing devices existing BIOS. 

Figure 3 illustrates an example of an operation of the 
device, for one typical step in a remote payment 
transaction. The other steps in the remote payment trans- 
action are carried out in a similar way. That is, they may 

25 require the operation of the message processor 105. They 

are event driven, such that the application 104 is called up 
to deal with any particular event after the event occurs, 
etc . 

The operation schematically outlined in figure 3 is 
30 that of reading information from a customers card and 

storing information in fields for subsequent processing by 
the application 105. In overall operation of the device, 
the information from the card will be required to identify a 
user and enable access to the user account to cause a 
35 transaction or authorise a transaction. 

Figure 3A illustrates example information in-cluded on 
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a magnetic stripe on a magnetic stripe card 5. The 
information includes track 1 information, track 2 
information, track 3 information, the customer name, the 
P7^, the expiry date and End-Of-Form label. This 
5 information must be taken off the card and stored in 

appropriately labelled fields so that it can be accessed to 
enable processing of the transaction. 

At step (1), on a card swipe of card 5 through reader 
4, the card swipe event is detected by the HW drivers 101. 

10 The HW drivers 101 causes a call back to an event table 

in HAL 102 for the peripheral card reader 4 which contains a 
series of names for routines to be performed on the occur- 
rence of a particular event on the card reader 4. There are 
also event tables for the other device periph-erals . 

15 Figure 3B is a schematic illustration of the event 

table for the card reader 4. Event "2" is for card swipe. 
In this example, there are three alternatives available for 
a card swipe event, labelled "1", "2" and "3". These labels 
may be dynamically updated in the event table, depending 

2 0 upon the particular stage of operation of the device. 

Label "1" is for the routine "handle idle card". This 
is a routine which is instigated where no payment 
transaction routine has yet been instigated, i.e., this is 
"kicking off" operation. 

2 5 Label "2" is the label for the "handle card" routine. 

This is where the payment terminal device is waiting for a 
card read event, e.g., where one has a device of the type 
which requires a money amount to be input before the card is 
read. 

30 Label "3" is where the device may be at a stage in the 

operation where it does not require a card reader, i.e., the 
card is swiped in error. In this case, nothing happens and 
no routine is initiated. 

Note that the above descriptions of the routines are 
35 not "primitives" but are merely general descriptions. 

It will be appreciated that the event table may contain 
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labels for any number of events to carry out operation of 
the device peripheral the card reader 4, Similarly the 
other event tables for the other peripher-als will be 
configured with labels for various routines they are 
5 required to carry out, as will be appreciated by the skilled 
person. It is not necessary to go into detail detailing all 
the routines, as they will vary from device to device and 
will be a matter of choice of the skilled programmer, and 
the operator of the payment terminal device. 

10 This event table driven structure is ideal. In a 

conventional terminal, where the terminal is executing 
sequential program instructions, for "handle card" rou-tine 
the device will merely sit in a loop waiting for a card to 
swipe. With this architecture, however, the device does not 

15 have to sit in a loop waiting for a card swipe. It can 

leave the applica-tion program and return to the HW drivers 
101 and in the mean-time the CPU 1 can be carrying out other 
jobs . 

With the event label, the sequence of the appli-cation 

20 in-struc-tions for the particular routine is then looked up 
via an index from the application 104. The function 
processor 107 is then called up, step (3) to com-mence 
imple-mentation of the instructions for card swipe. The 
function processor 103 then implements the instruction 

25 sequential-ly . The function processor 103 is a conven- 
tional inter-preter, as will be understood by those skilled 
in the art, arranged to implement the high level primitives 
of the application 104 via HW drivers 101. 

The first primitive requiring execution for the "handle 

30 card" routine in this example is the SAVE primi-tive, step 
(4). The first operation of the SAVE primi-tive is to call 
up the message processor 105. The mes-sage processor 105 is 
a series of several sub-routines implemented in the native 
code of the CPU 1, the specific operation of which is to 

35 construct, de-construct and compare messages in ac-cordance 
with message instruc-tions 109 from the application 104. 
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The SAVE primi-tive will have associated with it a label 
indicating the particular message instruction 109 associated 
with this particular event. The function processor 107 
fetches the message instruc-tion 109 for this event and the 
5 message processor 105 then operates to load the data from 
the card into labelled fields (steps 5, 6 and 7) according 
to the message in-structions . 

Once the message processor 105 has loaded the 
information from the card into the appropriate fields, in 

10 accordance with the message instructions 109, the SAVE 

function is completed and the device proceeds to carry out 
the next function in the sequence for "card swipe" fetched 
by the function processor 107. Alternatively, the sequence 
of functions for "card swipe" may be com-pleted and the 

15 device may wait for the next event before proceeding 
further . 

There are a number of ways that the payment transaction 
could continue once the SAVE function has been carried out. 
For example, steps could be taken to create a display asking 

2 0 the customer to input a PIN. Again, such steps would be 

carried out by the function processor 105 implementing the 
instructions, which would include a function to call up the 
message processor 105 to build a "foirm" to display the 
request on the screen. Alterna-tively, the device could be 

25 controlled to take steps with regard to the information 

loaded into the fields by the card in accord-ance with the 
SAVE function. For exam-pie, it could compare a PAN number 
taken from the card with an equivalent PAN number stored in 
memory of the device to establish the identity of the 

30 account acquirer. A skilled person will realise that a 

number of possibili-ties are available for continuing with 
the transaction, and would be able to formulate appropri-ate 
programming from this description and the following 
appendices . 

35 As discussed, the message virtual processor means is 

directed by message instructions 109. 
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Figure 11 is a schematic diagram illustrating the 
structure of the message instruction means 109. The message 
instruction means is in fact in the form of a set of 
"descriptions" of the messages. Each message usually 
5 comprises a plurality of fields 120, and the message 

instruction means for each message contains a corresponding 
plurality of message instructions.. One field may be the 
CUSTOMER N7\ME, for example. In the message instruc-tion 
means, each field is associated with a number of message 

10 descriptors 121 which designate characteristic to be applied 
to the information in that field or to be expected of the 
information in that field. Operations which may be carried 
out on the data included in that field may also be included 
in the descriptors 121. As illustrated in the drawing, the 

15 descriptors may include: 

1. Data Location Identification. This will indicate 
either where the data is to be found and/or where data is to 
be put. In the current embodiment the data location 
information is contained in a two byte field descriptor 

20 (thus having 65535 different possible values) with value 
ranges allocated to 

1) 2000 strings 

2) literal numeric values from 0 to 32,000 
in abbreviated form 

25 3) data field Ids where each ID is 

represented as an entry in a table, and each table may 
contain up to 256 fields. 

2. Data Representation {i.e. Ascci, Binary, etc.). 
This indicates what representation form the data is in 

30 and/or what it is to be converted to. 

3. Format. This provides a description of the format 
that the data is in and/or is to be placed in. 

4. Test Function. The index of a function processor 
set of instructions to determine if the current field is to 

35 be included or excluded at this time 

5. Line & Column. Relative position for use in 
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constructing messages for display or printing- These values 
are used to determine the quantity of space characters, and 
or new line characters that are required in the buffer. 

6. Substitution list. A list of text representations 
5 to substitute for numeric values e.g., display the value "1" 

as "Monday" and "2" as "Wednesday". 

7. Additional description options as required by the 
application or prove useful in future embodiments. 

Each message instruction will therefore include a 
10 description of a field of message data, providing 

instruction for the virtual message processor means which 
enable it to carry out a number of tasks: 

1. To compare a message with a message description to 
see if it is the correct required message. 
15 2 , To take a message of the correct descrip-tion from 

a location and place it in an-other location. 

3. To take a message and deconstruct it into various 
components and place the various components into other 
locations . 

20 4. To take data and build a message in ac-cordance 

with the message description and place the built message in 
a location. 

5, Compare one message with another message. 
Other functions may also be carried out by the message 
25 processor as required by the application. The message 
processor can manipulate data in any desired way in 
accordance with descriptions provided by the message 
instructions. Messages comprising data can therefore be 
billed, placed in locations, taken from locations, de- 
30 constructed with elements being placed in locations, etc. 
for subsequent operation on the data by the application. 
Any device which deals with significant amounts of mes-sages 
in such form can therefore benefit from this ar-rangement . 

Each message description is labelled so that it can be 
35 identified by the application, e.g. each message description 
may be numerically labelled. 
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A development tool for developing the applica-tion 104, 
in particular the message and protocol instruc-tions 108, 
109 comprises a graphical user interface based program which 
may be run on a PC or other general purpose computer. The 
5 program provides a graphical user interface based framework 
which en-ables message instructions to be built from data 
input by a programmer. Message instructions can 
subsequently be translated into code readable by the virtual 
machine 102, 101, 103 and downloaded into the application 

10 device. Figures 5, 6, and 7 are "screen dumps" which 

illustrate displays generated by the development tool for an 
example message instruction. In this case the message 
relates to data from a magnetic stripe of a customers card. 
The message instructions direct the message processor 105 to 

15 take the fields of the message and place them in known 
locations in accordance with the instruc-tions. Such a 
message instruction may be called up in response to the SAVE 
primitive, in the event of a card read. Data from the 
magnetic stripe of the card would be stored away in the 

20 appropriate locations in accord-ance with the instruc-tions, 
for subsequent process-ing. 

Each message is provided with a message name 30, in 
this case "TrackData". This message name identifier can be 
used to call up this particular set of message instructions 

25 in the development tool. An alternative niomeric identifier 
is generated for use by the virtual processor. This numeric 
identifier may also be displayed by the development tool. 
Each message is made up of a number of message "fields" 120. 
In this particular exam-pie, there are seven fields, being 

30 "Trackl", "Track2", "Track3", "CustName", "PAN", "ExpD" and 
"End-Of-Form" . Each of the seven field is converted to a 
message instruction for use by the virtual message 
processor. This is the information which is typical-ly 
found on any magnetic stripe card. The message in- 

35 structions in ac-cord-ance with this embodi-ment direct the 
message proces-sor to process these elements. Each field is 
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associat-ed with descriptors which provide further in- 
structions for the handling of that element. Figure 6 
illustrates a display 33 which enables a programmer to 
provide message descriptors to CustName element. 

Each field 120 has a "format" descriptor 34. There is 
an instruction as to the Data Represen-tation ("Type") 
reference numeral 35. In the illustrated em-bodi-ment there 
are four types, Ascll, Hex, Binary and BCD. There is also a 
logical operation instruction (option test) , reference 
numeral 36. This logic instruc-tion can be used to deter- 
mine whether or not the message processor will process this 
element at all, for example, i.e., it will only include the 
CustName element in the message when the logic function 
equals "True". Other instructions desig-nate the data 
source, reference numeral 37, in this case a field, and the 
field label, refer-ence numeral 39. The format 34 is 
labelled with a name, in this case, "Tracks". There are 
further instructions which dictate the format Tracks to be 
applied to CustName. Figure 7 shows a display which 
illustrates the instructions for the format "Tracks". 

The message processor is responsive to all the message 
instructions to load the data from the magnetic stripe card 
into the appropriate fields with the appro-pri-ate formats 
in accordance with all the rules designat-ed in the 
instructions . 

This embodiment of the present invention includes 
another class of message instruction means, known as a 
"Form". Instead of a Data Representation as a message 
descriptor, a Form includes description of a Location of the 
data field in the Form. Figure 8 is a display provided by a 
development tool enabling the programmer to prepare message 
instructions for a Form message. On the left hand side of 
the display a panel 70 illustrates Form layout. The fields 
in the Form include MerName, Address Line 1, etc. The 
location of these fields can be moved within the panel 70. 
The location in the panel is provided as a descriptor and 
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for the message instruction. The Form type of message in- 
struction controls displays, reports, print-outs, and the 
like. The type of Form is given by the instruction 
designated by reference numeral 71, in the example 
5 illustrated in figure 8 being a print-out. The message 

processor takes the fields from known memory locations or 
other locations and enters them in the locations enabling 
the Form described by the Form instruction to be produced. 



10 SNAC device is communications. For example, it is necessary 
for the majority of remote payment transactions for 
communications to be able to occur between an account 
acquirer location, in order to enable access to an account, 
and the remote payment device. Communication with a data 

15 carrier, such as a smart card device may also be required. 

The protocol processor 106 is arranged to organise 
communications, in accordance with directions from the 
protocol processor instructions 108. Referring to Figure 4, 
in a typical remote payment transac-tion, after a card has 

20 been swiped, a PIN number has been input and a charge amount 
has been input, information then needs to be communicated to 
an external computer, at the account acquirers, in order to 
enable further processing of the transaction. After an 
event such as a communications message arriving, therefore, 

2 5 HAL 102 detects the event (step 1) and activates the 
protocol processor (step 2), figure 4. The protocol 
instruction 108 for the event is rolled up (step 3) . The 
protocol processor 108 implements the protocol in-struc- 
tions for that event, (step (4)). 

30 The protocol instructions are divided into "sections" 

130, "lines" 131 and "protocol commands" 132, as illustrated 
in Figure 12A. Figure 12B illustrates how an instruction is 
displayed on a development tool for protocol instructions. 
Protocol instructions describe message flow both from and to 

35 the device. The top line specifies outgoing messages and 
the other lines display possible incoming results. A 



As discussed previously, another major function of a 
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protocol consists of lines and sections. At the start of 
each section is a line 1 (optional for the first section) 
which describes the outgoing message. There are a number of 
protocol commands, and these include: 
5 1 . Protocol - Run a sub protocol 

2 . Message - Send a message or handle an 
incoming message using the. virtual message processor means 

3. Retry- re execute the steps of protocol from 
and indicated point 

10 4. End - . End of the protocol 

5. Exit - Stop the protocol from an 
intermediate point 

6. Timeout 0 - Specify the a delay after which 
the protocol should automatically jump to the point at which 

15 the timeout instruction is placed. 

7. Control - Specifies a control character to 
be send or received. 

8 . Function - Execute a virtual function 
processor function 

2 0 Protocol instructions are organised in lines and 

sections- In each section Line 1 indicates the information 
to be send by the SNAC device and subsequent lines indicate 
actions to be taken in response to the alternate possible 
events which may occur in reply. The first instruction on 

25 each of these subsequent lines is used to identify the 

response. Control () , Message (), Function and timeout () may 
all be used to identify responses as follows. 

1) When the time specified by a timeout instruction 
elapses then the line commencing with the timeout will be 

30 selected. 

2) When data is received it will be sequentially 
compared to a lines commencing with Control () Message () or 
Function to see if the data matches the control character, 
matches the message of causes the test contained in the 

35 function to evaluate to true. 

Figures 9 and 10 illustrate displays of a development 



SUBSTITUTE SHEET (RULE 26) 




wo 98/41918 PCT/AU98/00173 

. - 31 - 

tool for protocol instructions for the protocol "General" 
which is the Protocol Name (refer-ence nuineral 42) . 
Instructions are presented as a screen dump in the form of a 
table 43, which can be accessed by a programmer if he wishes 
5 to alter the protocol. 

Protocols are arranged to control message flow both 
from and to the target device (e.g., account acquir-er 
computer) . The top line of the display panel 44 specifies 
outgoing messages and the other lines display possible 

1 0 incoming results . 

A particular protocol is able to call up other 
protocols "nested" within it and is also able to call up the 
message engine to deal with messages. 

Referring to figure 10, the top line of panel 44 

15 specifies the outgoing message. The first operation of 
protocol "General" is to call up and carry out a further 
protocol, "Reversal". Figure 11 illustrates instructions 
for the protocol Reversal, reference numeral 45. Rever-sal 
operates to call up the message engine to construct message 

20 number 0400 and this message is then sent to the target 
device . 
The either 

1) Message number 0410 should then be re-ceived back 
from the target device and the message pro-cessor will be 

25 called up to deal with that data, which involves the message 
processor comparing the incoming mes-sage against the 
description specified by the message in-struction means and 
storing the data if a match occurs. Or 

2) A timeout of 100 tenths of a second elapses. 
30 Then the protocol is ended and re-turned to the 

protocol General, which causes a further message, 0100 to be 
formulated and sent out. 
Then either 

1) A message matching 0110 will be received or 
35 2) A message matching 820 will be received or 

3) neither 1 or 2 will occur for the timeout () 
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15 
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30 



period, in this case specified as 000 tenths of a second. 

If the message 0110 should then be received from the 
target device and compared by the message engine, then 
another protocol "adjustments" will then be carried out. 
The protocol would then end. 

If the message 820 should be received from the target 
device, which can be dealt with by the message engine and 
compared with the instructions from the mes-sage instruction 
means. The "Retry" instruction will then be executed 
causing the virtual protocol processor to move execution 
back to the sending of the (0100) message. The retry count 
of zero indicates this loop would continue whilst 820 
messages are received. 

If the Timeout occurs, then the retry (5) would be 
applied causing the protocol processor to move execution 
back to the Send 0100 message. This loop would occur up to 
five times as indicated by the retry (5). After the fifth 
time execution would move to the next section causing the 
protocol to End. 

More details of operation and build up of mes-sages and 
protocols are given in the appendix A. 

The device in accordance with the present invention, 
for example a payment terminal, may be implemented in GAVA 
by defining a class library payment terminals. This class 
library would contain calls to all the functions of how HAL 
and preferably the message and protocol engines. Similarly, 
a specialised network access computer or card computer could 
be implemented in GAVA. 

Please note that the arrangement of the present 
invention can be used to deal with any payment transac-tion 
device, including one which deals with smart cards. 

The present invention can also be used to imple-ment a 
specialised network access device, which may use similar 
hardware to that provided for a payment terminal . 

In the attached Appendix A, the term "CardScript" is 
the name the applicants have given to programming required 
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to implement this embodiment of the invention. 

It will be appreciated by persons skilled in the art 
that numerous variations and/or modifications may be made to 
the invention as shown in the specific embodi-ments without 
5 departing from the spirit or scope of the invention as 

broadly described. The present embodiments are, therefore, 
to be considered in all respects as illustrative and not 
restrictive , 

APPENDIX A 

10 

Contents . 
Introduction 
15 Introduction 

Help for CardScript Scribe 

The Scribe program assist in the design of stored 
20 information & programs for EFTPOS terminals, PINpads, 

Electronic Cash Registers and other small computer systems. 

Writing A Program 

25 For help on writing a CardScript, program, rather than 
operation of the Scribe tool, see 

Writing A CardScript Program 

30 A CardScript program is more similar to a Windows KAD tool 
program than a conventional C Language or Assember program. 

The "target" device has several keys, one or more card 
readers, and usually one or more communications ports, 
35 Defining a program consists of attaching actions to these 
events, or the special events of terminal power on and 
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CardScript programs - as all other program - manipulate 
data. Data is defined in a Data Dictionary. Unlike normal 

5 programs^ it is normal to write many CardScript programs 

using the same Data Dictionary, Standard Data Dictionaries 
are available from CardSoft for EFTPOS and several other 
application types. It is recommended to write initial 
applications based on one of these standard dictionaries. 

0 Once the program is experienced, the Data Dictionary for an 
Application may be modified, see 

Configure Data Dictionary 

5 Data Dictionary Usage 

The Data Dictionary represents the list of all "variables" 
or information values used in the target device. These 
"variables" are in formation which may change over time, or 
0 be different from device to device. 

Information which is fixed for all devices usually is 
defined by strings. All information to be included in 
displays, receipts, messages etc, comes from either the Data 
Dictionary or from STRINGS. 

5 

Data Dictionary fields may have an initial value set from 
the Initial Data Tables 

Structure 

0 

Tables 

The Data Dictionary is divided into tables. Each record 
displayed in Configure Data 
5 Dictionary describes one table. Fields are placed by 
selecting add and clicking on the Panel. 
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Field Attributes 

Double Clicking on any field reveals and allows viewing 
5 and/or editing of Data Dictionary Field Attributes. 

Field Order 

Layouts are stored indexing fields by table#lf ield# . This 
0 means existing scripts will behave strangely if the Data 
Dictionary is changes the number Of referenced fields. 

For example if "Merchant Name" is table 3/field 2 and 
"Address" is table Slfield 3. Then deleting field 

5 table3/f ieldl will make any prior references "Merchant Name" 
now reference "Address". This can be remedied by inserting 
a dummy table3/ field 1 as a placeholder. Generally this 
problem does not arise since new dictionaries are not to be 
used for old applications, and existing dictionaries are 

0 usually only extend. In the rare event that a dictionary 
used by existing applications is to have fields deleted/ it 
recommended to rename them to "dummy" or "unused" . 
Be careful since any existing data in the files will be 
rearranged when retrieved, it will simply be move from the 

5 record into the fields in the order listed at the time. 

New fields added in graphic display mode are always added at 
the end 

Reserved Settings 

0 

see Reserved Data Dictionary Settings 
see also 

5 Data Dictionary Field Attributes 
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The field attributes which may be set are as follows 
Type 

5 Type refers to the format in which data is held. "X-Ref ' is 
a special value used to indicate that another table will be 
referenced at run time and thus must be included in the 
build. 



10 Binary Data Fields 



Binary, either 1 or 2 bytes in length for Integer values in 
calculations, longer fields hold bit fields or keys. 250 
bytes is the maximum permissible number of bytes 

Maximum Integer values 



20 



Depending on the number of bytes used to represent the 
Binary number, the following values are possible 



1 Byte - O. . 255 

2 Byte - O. . 65, 535 

3 Byte - O. . 16,777,215 

4 Byte - O.. 4,294,967,295 
25 Text - up to 250 bytes 

BCD up to 250 bytes 

Date / Time (2 Bytes for Dates, 2 or 3 bytes for Time) 
see Date & Time Fields 

Amount - 10 bytes, internal format is target device 
30 dependent 

Packed Amount - not currently used 

X-Ref - Advanced use only 

Flags 

35 0 = Field is fixed and never reset 
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1 = Reserved for future use 

2 = Reserved - used with deleted fields 

5 3= Field is reset when terminal is loaded 

4 = Field is reset at power on 

5 = Field is reset by idle function 

10 

Bytes 

The leright of stored data in bytes 
15 Length 

Caution: When you create new data dictionary fields, make 
sure their leright is not zero if you want to use them, or 
they will be invisible. 

20 

The niomber of characters allocated to display the field as 
text 

Name 

25 

The name of the field for display on receipts etc. 
Table 

30 The "refer" Initial Data File from which the field initial 
value is extracted. Blank if the field is extracted from 
the default file. 

Table Idx 

35 

When "Table" is non-blank, "Table ldx"specif ies the "refer" 
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of the Initial Data Field in the default file used to 
indicate the record number in "Table" from which data is to 
be extracted. In other words the join field between the 
default table and the joined table. 

5 

Field 

The "refer" of the Initial Data Field from which the initial 
value of the field is to be obtained. 

10 

Creating a New Application 

As suggested above to create any application, it is 
recommended to copy a "template" application. Simply copy 
15 the entire template directory. 

To then work with the new directory, select 
File/Installation and edit the data directory. (Don't 
forget the trailing I) Is the recommended to exit Scribe 
20 and restart. Scribe and restart. 

Console/Display 

The display console used with CardScript is quite 
25 sophisticated, see 

The Console 

CardScript can be used in a variety of devices, some of 
30 which may not support all the features described here. 

Features 

The CardScript Console has a number of sophisticated 
35 features 



SUBSTITUTE SHEET (RULE 26) 





wo 98/41918 



PCT/AU98/00173 



39 - 



10 



15 



20 



25 



30 



Hot Keys 

Keys used to launch only one action, where the action is 
part of the application, are known as hot keys. Typically 
the action may be activated only when the terminal is idle. 
For further information see the "KeyBd" primitive. 

In an EFTPOS application, on a terminal with Keyboard 
Buttons available for allocation. Hot Keys will normally be 
allocated to such functions as "Sale", "Adjustment", "End of 
Day" etc. 

Hot keys normally would have their label printed on the 
keyboard, or on the physical button. 

Multiple Field Input 

On any Layout displayed on the console, several field may be 
selected for input. The OK key steps from one input to the 
next. Any soft key terminates all input. 

Scrolling 

The display may be scrolled, permitting a larger virtual 
display than the physical display. Scrolling is performed 
automatically by the driver in the target device. All that 
is needed to enable scrolling is to tell the scrolling 
driver what keys on the keyboard perform scrolling. The 
keys used to scroll are set by the 

Console Primitive 

Console (Command, Parameter) 

The command determines which of the following console 
options is set. 
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Command I- Set Scroll Keys 



The Parameter is a string of four hex values, in order - 
5 key-left, key-right, key-up, key-down 

The keyvalues specified are assigned to the scrolling engine 
within the target device. Note scrolling my not function on 
all CardScript "targets" and the size of the scrollable area 
10 may vary. 

Command 2- Set Keymap 

The parameter is a Key board map. This command is now the 
15 preferred method for setting the keyboard map. The old 

Keymap primitive will be obsolete in a future version. See 

KeyMap 

20 Structure of Keymaps 

The" field" or String used as a keymap must be a list of 
4digit hex blocks, the first two digits of each block 
representing the hex code of the key to be mapped and the 
25 next two digits representing the hex value to map be 

returned. Usually used from the startup function, using a 
field from the terminal groups record. 

Note that the following key codes have special meaning. 

30 

08 

Represents a backspace or'CLR'code. 
OA 

35 Represents an 'OK or 'Enter 
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Represents a cancel, 
30 through 39 

Represent the digits "0123456789" 
Command 3 -Keybd 

The parameter is evaluated to zero, or non zero. 

Upon entering idle state, the action of the keyboard is 
determined by the last KeyBd command. The keyboard (except 
cancel) will be ignored if off was specified. 

This command replaces the old keybd primitive, which will be 
obsolete in a future version. 

Command 4- Invalid Entry 

The parameter is the text message to be displayed. 

This command is designed to be called from an input 
validation function. Calling this command indicates the 
input is invalid, the text specialised in the parameter 
should be display to indicate the error. 

Soft Keys 

Some keyboard buttons on a target device may be used as soft 
keys. As opposed to Hot Keys these are buttons which may be 
used to initiate different actions, depending on the display 
present when they are pressed. 

Since the principle of Soft Keys is to use the same buttons 
for different actions, displays must in some way indicate to 
the user the operation of each currently active soft key. 
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Soft Key Button Sets 

Target devices may allocate certain buttons on the keyboard 
5 for use as soft keys. Button sets are numbered from zero. 
If a specified set is not available, then set zero is used. 
By convention:- 

Set 0 = keys ' 0' thru' 9' (the numeric keys) 

10 

Set 1 are dedicated soft keys, usually positioned directly 
adjacent to the display, in order that the display may be 
easily used to indicate their function. 

15 Set 3 is the new standard for dedicated soft keys - hex 
values 81, 82 . . AO. 

Set 3 will normally be requested on forms where numeric/text 
input is also required, 

2 0 Set 4 is the same as set 3, but allowing use of the numeric 
keys if no dedicated soft keys are available. Set 4 should 
not be specified on screens where numeric input is also 
available, since this may cause a conflict. 

2 5 Soft Key Action Groups 

These are the groups of actions that may be offered at any 
given time. 

30 In Layouts/ Forms, a soft key action set may be selected for 
any display. Individual functions may be assigned to an 
action group from the Function/General Purpose Functions, in 
the Function activation section. 

35 Note Action group 0 is used to indicate a function is NOT 
part of any group 
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Correlation of Actions to Buttons 



If a display allows soft key Button Set 0, 
5 (Keys'O', '1', '2', '3' etc ) and action set"I'then when the ' 2 ' 
key is pressed, then soft key group' 1' , An Group' 2' 
(Key'2'minus the first key in the action set equals 2), if 
it exists, will be activated. 

10 The Keyboard 

To control the features available, and make best use of your 
terminal, you can recode the keys on your keyboard using the 
keymap primitive. This allows you to customise the target 
15 device to allow portable and easy to operate applications. 
See 

Keyboard Codes 

2 0 The Keyboard codes are designed to accommodate a wide 

variety of keyboard configurations. At any given time each 
key (or button) will act as one of the following key types 

1 Control/Data Entry Control 
2 5 2Data Entry 

3Soft/Hot key function activation 

Control/Data Entry Control 

30 Some keys are required for control. Control keys should not 
be used for any other purpose than control, otherwise the 
user interface will incredibly confusing. 

Minimum Requirements 

35 

All CardScript drivers should provide these key codes 
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without any mapping required. 

08 Backspace or Cir 
IB Cancel 

5 OA OK or Enter 

lA Fn -For general Function selection, and for double (or 
tripple) zero. 

Additional Options 

10 

OD or complete foinn (combined with tab as an alternativ to 
OA) 

09 Tab (move to next field- does not complete form) 

OB Vertical Tab - Used as back tab or move to prior field. 
15 11 (XON)DCI - Used as cursor left 

12 DC2 - Used as cursor right 

13 DC3 - Dedicated double zero 

14 DC4 - Dedicated Function Key (combined with DC3 as an 
alternative to 1 A) , 

20 

Data Entry 

Three levels of data entry may be available at any one time. 
Text, Hex, Alpha. The bios can automatically determine the 
2 5 available level and act accordingly. 

Minimum Requirements 

30.39 (Numerics) 

30 

Additional Options 

A B C D E F (allowing Hex data entry) 
Ful 1 ' quert y ' keyboard 

35 

Soft & Hot keys 
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Soft keys previously were recoininened to be 'a"b-c' etc 
Now the are recommended to be hex 81 82 83 etc up to a 
maximum of AO allowing upt to 32 dedicated Soft keys. The 
5 change in recommended values is to allow for terminals with 
full alphabetic keyboards. 

Hot Keys (When/Additional to soft keys) should be allocated 
from Al , • . DO 

10 

Program Portability 
Portable Programs 

15 CardScript allows the writing of totally portable programs, 
it is also possible to write programs that are not very 
portable. Any CardScript program will "execute" on any 
CardScript enabled target, however the result could be of no 
use on the target if special hardware characteristics are 

20 required for practical operation of the program. CardScript 
provides a mechanism for avoiding the traps and keeping 
programs portable whilst still taking advantage of special 
hardware when available. 

25 Keyboard Traps 

The key map primitive represents a trap in that this 
function should never be used with a literal string, or your 
program won't be portable. 

30 

Processing Cards 

Magnetic Cards 

35 Automatic Processing 

Automatic Magnetic Card Processing, from 
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Upon Card read, data from the card is placed int the Receive 
buffer. The format in the buffer is 

5 Track 1 (I terminated) 
Track 2 (I terminated) 
Track 3 (I terminated) 
Customer Name (I terminated) 
PAN (I terminated) 
10 Expiry Date (6 bytes ASCII) 



If the read occured at terminal idle, the Cacluation Result 
is set to zero and the system event Magnetic Card Read is 
generated. After executing any function for the Magnetic 
15 Card Read Event, if the Calculation Result is non zero this 
value is used to select a function for further processing of 
the specific card type. 



Automatic Magnetic Card Processing 

20 

Upon card swipe, the data dictionary fields 
Transaction/Track2 tru Transaction/Customer 
Name are filled with the card details. These are data 
dictionary fields Tablel/Field2 thru 
25 Tablel/FieldV . see Reserved Data Dictionary Settings for 
details . 

Table 5 is then scanned to find a column matching the PAN of 
the swiped card. If a column in table 5 is found then the 
tables 3 & 4 have their columns set according to the entries 
30 for Issuer & Acquirer in Table 5. 



Table 5 is set during the build to indicate the appropriate 
action should a card be swiped at idle. If the teminal was 
idle at the card swipe this function is now executed. 

35 

Typical Processing . 
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For standard processing, create a function as follows 

store (O, CardMsg) 
5 if ColFind (Pan, PanLow, PanHigh) 
ColSelect (Issuer, IssuTbl) 
ColSelect (Aquirer, AcqTbi) 
Exit (O, CardFunc) 

0 Smart Cards 

Two primitives are available for controlling Smart Cards. 

Card (Command, Field/Value) 
5 lA command of 1 is used to read the smart card status into 

the field "FieldNalue" . Using a value for "FieldNalue" does 
achieves nothing. 

2A command of 2 is used to control the power to the card. 
0 If "FieldNalue" is 1, the card is powered on, if 
"FieldNalue" is 0 the card is powered off. 

3Select. A command of 3 is used to select which smart card 
reader (or plug in is surrently selected. By convention, 1 
5 is the user card (or if only one reader is present, this 

reader) , 2 is the separate merchant card slot or the plug 
in, where present. "FieldNalue" contains the card number to 
be selected. 

0 4A command of 4 is used to read the Smart Card Type Code 

5A code of 5 performs a logical test on smart card type. If 
the field/value supplied matches the Smart Card Type Code of 
the current code, the logical true flag is set. This 
5 command is designed to be used in an "if" test 
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6Code 6 reads the CardEntryMode into the specified 
FieldNalue. See CardEntryMode 7Set Card entry mode to the 
value specified in FieldNalue 

5 see Also 

TPDU( Command, SendMsg, RxMsg, Status ) 

The TPDU primitive is used to send a command to the card. 
10 If the TxMsg is present this data is also sent to the card. 

If the RxMsg is present then a response is expected from the 
card and is stored in the RxMsg buffer. 

Command 

15 

This if the actual 5 bytes TPDU to be send to the card 



20 This optional parameter specifies the message used to build 
the data send to the card. 



25 This optional parameter specifies message used to store any 
data returned by the card in response to the TPDU, 



30 This mandatory message specifies the location of status 
variables to record the status of the TPDU operation. 

The TPDU primitive with Synchronous (Memory Cards) 
416 Cards 

35 

Drivers for 416 Cards support the following TPDU Commands 



SendMsg 



RxMsg 



Status 
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ReadBytes 
WriteBytes 
EraseBytes 
Present Key 
5 see Commands for Memory Cards 

The present Key uses the lenght indicator to select either 
the CardSecret Code (2 bytes) or the application erase 
secret code (4 bytes) 

10 

Answer to Reset, & Card Type 

The 416 has a card type code of 4 and an answet to reset of 

15 3Bh 00 00 00 00 00 

Commands For Memory Cards 

ReadBytes 

CL (any) 

20 

INS BO 

ADDR XXXX (Byte Address an Card) 
2 5 LN LL Niimber of bytes to read. 
Wf iteBytes 
CL (any) 



30 



INS 



DO 



ADDR XXXX (Byte Address an Card) 



35 



LN 



LL 



Number of bytes to write. 
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EraseBytes 

CL (any) 

5 INS DE 

ADDR XXXX (Byte Address on Card) 

LN LL Number of bytes to erase. 

10 PresentKey 

CL (any) 

INS 2 0 

15 

ADDR XXXX (Byte Address on Card) 

LN LL Lenght of Key. 

20 Other Smart Card Commands 

For selecting the smart card reader, and control of the 
reader. 

For sending information to the card, and receiving 
2 5 information from the card. 

Smart Card Type Codes 

1 Async ISO type Card 
30 2416 

Asynchronous SCHLUMBERGER type EE2K 

Asynchronous SCHLUMBERGER type EE4K. 

Asynchronous SCHILUMBERGER type EE16K. 

Asynchronous type GPM256 
35 Asynchronous generic type 12C BUS 

Asynchronous type GFM2K 
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9 synchronous type GFIV14K 

For coding of smart card types. 

Running A CardScript Program 

5 

To run the program on the PC simulator, see 
PC Simulator 

10 There is a impimentation of the CardScript Virtual machine 

available on the PC that not only runs your program, it also 
emulates the keyboard layout and other controls of any 
target machine. 

15 To run the simulator - select "Build/Run Simulation of 
Build" 

Stored Information - Data Tables 

2 0 For Information on setting & changing values in the Data 
Tables See - 
Tables Menu 

CardScript includes all tools for maintaining data tables to 
2 5 control the setup and distribution of Data Tables required 
for any application. 

The System Data Table 

30 The system data table has a fixed format identical in all 
systems. This table contains general information and 
current setting for use within the scribe program. 
See - 

System Table Settings 

35 

Settings in the system table are used to both miscellaneous 
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settings in the script, and options for viewing the script. 
Loader Settings 
5 Terminal For Mask Load 
Not used by scribe 
Default Prompt (or String) Table 

10 

The string table displayed within Scribe. Multiple string 
tables may be used to support multi language applications. 

Peripherals 

Description the peripherals of a the target system here and 
displays and reciepts will in scribe will show guides to 
assist in design. These setting have no affect on program 
execution in target devices and may be changed at any time. 

Reserved Functions 

Idle State 

25 Set this pointer to indicate a function to be executed each 
time the"target" becomes idle . 

Abort 

30 Normally left at <none> since applications may vary default 
options during execution. 

Initial 

35 This function is executed at "target" power on, . 
Processor 



15 



20 
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10 



15 



20 



25 



30 



Previously used to indicate the byte order used in the 
"target". It is now recoimneded to use "Low-High (INTEL)" 
for all systems. 

Configurable Data Tables 

The data tables used by CardScript can have their names, 
field names / layout and even the number of tables used 
altered according to the current system setup. 

Configure Initial Data 
Initial Data Usage 

The purpose of initial data tables is to provide a database 
of information for initial values for the data dictionary 
loaded into the target device. 

Configuration 

Structure 

Each record in the configuration describes one table. 
Fields are placed on the Panel and dragged to the 
appropriate position. 

Field Atttributes 

Double Clicking on any field reveals and allows viewing 
and/or editing of Initial Data Field Atributes. 

Field Order 

Clicking on "Graphic Display" toggles between the standard 
graphic view of the fields and a simple ordered list of the 
fields. In the ordered list mode fields may be dragged to 
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rearange the field order. 

Be careful since any existing data in the files will be 
rearranged when retreived, it will simply be move from the 
record into the fiels in the order listed at the time, 
5 New fields added in graphic display mode are always added at 
the end. 

Reserved Initial DatalSase Settings 
10 Certain fields must be present in the for the build process. 
File Usage 

File 1 - "Terminals". The name may be changed however this 
15 file is used to initialise individual target devices with 
the optional "NetMgr" module. No other special usage at 
present 

File 2 "Groups" - no special considerations 
20 File 3 "Issuers" no special considerations 
File 4 "Aquirers" no special considerations 

File 5 "Card Ranges" - must be used as card ranges, and must 
have fields "lo" "hi" and "len" 
File 6 "Products" no special considerations 
25 File 7 "Region Settings" no special considerations 
File 8 "Issuer Sets" no special considerations 
File 9 "Card Sets" must contain the fields "cards" as an 
index into card ranges 
see also 

30 

Initial Data Field Attributes 

Type 
Flags 

35 

Current usage 
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Repeat 

5 

The number of times the field is to appear on the form 
X-Pos 

10 The current value of X-positon of the field on the form. 
Usually modified by dragging the field. 

Y-pos 

15 The current value of Y-positon of the field on the form. 
Usually modified by dragging the field. 

Label 

2 0 The label to appear for the field on screen. 

Refer 

The "refer' label used to access the field when building the 
25 initial data dictionary 

Display (Type = Text only) 

The number of characters to be displayed on screen. 0 (zero) 
30 for default. 

Size 

Functions 

3 5 For information on defining functions in your application 

see - 
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Functions Menu 

see also Function Primitives 

5 

For Describing any function within the "target" to the 
system, or in program terms for writing scripts see 

General Purpose Functions 

10 

Use this selection for describing functions 
Label 

15 The function name 
Description 

A brief descrition of the function. The function can be 
2 0 located by description 



A window to the function actions. Doiible click on this 
2 5 window to see or edit the full Function Action, see also 
Function Primitives & Function Primitive Catagories. see 

Function Action 

30 Double clicking on a function action block brings a panel 
into view for editting the function actions. 

Adding Actions 

35 Select the apprioate action from the alphabetical list 
beside the add option, select add and then click on the 



Action 
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panel at the appropriate postion. Clicking over an existing 
action will insert the new action before the existing action 

Deleteing, Actions 

5 

Select delete and click on the action. Take care to deslect 
delete before clicking on other actions. 

Editting Actions 

10 

Double Click on any action to activate the edit dialog box. 
Function Index 
15 Shown for reference purposes. Cannot be changed. 
Strings 

See your driver information- Currently this information is 
20 not used by most drivers. 

Function Activation 

Specifies when this fuction will be executed, see 

25 

Starting A Function 
Function Number 

Each function may be assigned a number. The operator may 
30 then enter the number and the program easily select from the 
list using the Function# primitive. 

Hot Key Code 

35 Each function may be assigned a hot key code. Enter a non- 
zero code in HEX and if a key with this code is pressed at 
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idle, or any other time hot keys are activated, the function 
will be activated. Note that the Cancel Key is regarded as 
as system event. 

System Events 

System Events are similar to hot keys, only instead of keys 
being pressed (Note that the Cancel key, IS a system event), 
other actions on the target device are involved. For each 
) target machine a list of System events is maintained, but 
these should always include the standard events. Only one 
function may be assigned to any System Event. 
See 

':> Standard Event Codes 
Keyboard. 

Keys on the keyboard with a value less than 128 (0x80 
hexadecimal) generate an event code with the value of the 
) key. 

Other event Codes 

0 ^Reserved 
5 1 System becomes Idle 

2Cancel Key Pressed 

3System Power On 

4Numberic Entry 

SSmart Card Insertion 
0 6Smart Card Extraction 

7Magnetic Card Swiped 

echecksum Error Detected on Batch 

9Checksum Error Detected on Data 

5 Card Set 
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Select a card set. When any card belonging to this set is 
swiped at idle, the function will be activated. 

Usage Flags 

5 

Operator Function - The operator of the target device 
selects the function 

Library Function - The function is an internal "subroutine" 
Not Used- The function is not used 
10 For adding actions to functions which may be varied by 
issuer or by acquirer see 

Transaction Function Input 

15 Transaction Function Approval 

Function Primitive Catagories. 

Function script is a sequence of calls to system and user 
20 primitives. For information ol 
primitives available see 

Function Primitives 

25 Assignment Primitive 

Fieldl := String/FfeW 

Set fieldl to the string/ field2 . 

30 

=> (goes to) primitive 
=> field 

35 The vaule of the last logical or other operation using the 
"calculation result" is stored in field 
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specified 
eg 

Account == 000 
=> zAccount 

5 

Would set the field zAccount to 1 if Account was zero, 
othersize zAccount would be zero. 

=> result (goes to) primitive 

10 

=> field 

The vaule of the last logical or other operation using the 
"calculation result" is stored in field 
15 specified 

eg 

Account == 000 
=> zAccount 

20 

Would set the field zAccount to 1 if Account was zero, 
othersize zAccount would be zero. 
see also 

25 Calcuation Result. 

Calculations generate a "Calcualtion Result". Think of this 
value as the value you would see on the display of a 
calcuator if the caluculation was performed on a calcuator. 

30 

Math Primitves 

Fieldl += Number/Field2 

Fieldl -=Number/Field2 

35 Fieldl *=Number/Field2 

Fieldl /=Number/Field2 
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Fieldl is modified by thef ield2/nuinber . 
Relational Primitives 

5 

Fieldllvaluel < Field/value2 
Fieldlvaluel > Field/value2 
Fieldlvaluel == Field/value2 

10 The two fields or values are compared. If one field is text 
and the other numeric then the return value will always be 
false . 

<> != >= 

For not equals (whether thought of aso or!=), greater than 
or equals (>=) and less than or equals (<=) use the opposite 
case. With the WHILE PRIMITIVE and REPEAT UNTIL primitive 
then use the NOT option. With the IF PRIMITIVE use the ELSE 
clause. 

Abort Primitive 

abort 
25 

Thisprimitive causes the target device to stop all functions 
and become idle 

Alarm Primitve 

30 

Alarm (noise type) 

Makes the sound specified 
1 error alarm 
35 2bip type noise 

3most severe alarm 



15 



20 
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Bit Manipulation 
Bit Numbering 

5 All binary fields can be accessed as a number of bits where 
the number of bits no . of . bytes*8 

The MSB of each byte has the highest bit number and the LSB 
the lowest bit number. Note ISO bitmaps do NOT follow this 
10 rule, but these do not need bit manipulation by the 
application . 

This result in the LSB of the last byte being bit 0 (zero) 
and the MSB of the first byte being no.of .bytes*8 -1. Eg 
15 for two bytes 15. 

Bit count Primitive 

bitcount (field, start, end, bitvalue) 

20 

start & end 

These are both bit numbers- see bitnumbering . Direction of 
counting is from start to end, either may be the larger 
25 number. 

bitvalue 

0 indicates count zeros 
30 1 Indicates count ones 

2 Indicates counts zeros and stop at the first non zero bit 

3 Indicates count ones and stop at the first bit no set to 
one . 

35 Notes 
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10 



15 



20 



25 



30 



The numer of sequential bits of the value "bitvalue" 
starting from bit "start" and working towards "end" is 
counted . 

If the result is non-zero the logical true status is set, 
otherwise the logical false value is set, allowing "if type 
tests of the result 

The count is stored as the "working value" allowing storage 
via the "->" (goes to) primitive, see -> (goes to) primitive 
Setbits Primitive 

Setbits (field, startbit , endbit, value) 

Bits number "start bit" thru "endbit" are set to the value 
"value" . No all values are extracted from the least 
significant bits of value, e.g. For a 1 bit field, all 
values are considered either 1 or 0. (Odd numbers are 1) 

Batch Primitive 

Batch (Operation) 

Operation 0 = reset to first txn in batch 
Operation 1 = find & restore next txn 
Operation 2 = delete current transaction 
Operation 3 = delete all transactions 

CardRead Primitive 

Card (string, field form, default) 

This primitive is identical in operation to the show 
primitive, with three extra facilities 

llnput is tenainated by either the introduction of a smart 
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card, or the swiping of a magnetic card, 

2Data from a magnetic card read is stored in the reserved 
fields 

5 

31f the (card entry mode) is non zero, this primitive does 
nothing. This allows logic to read a card only if the card 
is not already read. 

10 See also 

Example 

A function requiring input of both "Tip Amount" and "Cash 
15 Out Amount" can input both using the same field. 

Create a form as follows. Edit the PFIELD to indicate an 
input field. 

20 PSTRING Name: Form 

PFIELD 

Create a function 

25 Show (Tip, TipAmt, Form, 0) 

Show (Cash, CashAmt, Form, 0) 

Where "Tip" and "Cash" are strings. On the first call to 
3 0 show the display will prompt "Tip" and accept input into the 
TipAmt field. On the second call to Show the display will 
prompt "Cash" and accept input into the CashAmt field. 

Show (string, field jorm, default) 
35 Action 
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This primitive is specialised for displaying input forms. 
Two parameters (string and field) substitute with PSTRING 
and PFIELD in forms, allowing the same form to be used for 
multiple inputs. 

String 

String to replace the PSTRING field on the form, <none> if 
unused. 

Field 

Field to replace the PFIELD field on the form. 
Form 

The Form may be selected from the list box- or alternatively 
by selecting Field- >Value [X] taken from a field in the data 
base . 

Default 

A value of one (1) if the existing value of the field is to 
be displayed as a default, otherwise 0. 

Reserved Data Dictionary Settings 

The driver in the "target" makes direct use of some fields 
in the data dictionay. Using these table#/f ield# settings 
for other use will have strange results and is not 
recommended. 

Table 1 (Transaction Table) 

Fields in this table may be initialised to default values 
only. The first fields in the transaction table are 
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IROCNUM 
2Track 2 
3Track 1 
4Track 3 
SPAN 

6Expiry Date 
7Custoiner Name 
SProtocol Status 
9Card Entry Mode 

Table 2 (Totals Table) 

No reserved settings, however a fixed ten copies are 
available. Initialisation of fields to default values only. 

Table 3 (Terminal Table) 

This table is the basis of the build of terminal groups, and 
may be initialised from the Initial Data Table. There is 
always only one record in the table. 

Table 4 (Issuer Table) 

One record per issuer, with the current record selected 
automatically when a card is swiped. 

Table 5 (Acquirer Table) 

One record per acquirer, with the current record selected 
automatically when a card is swiped. 

Table 6 (Card Table) 

Fixed layout. Dictionary specification currently ignored. 



SUBSTITUTE SHEET (RULE 26) 



wo 98/41918 



- 67 - 



PCT/AU98/00173 



Coffind Primitive 

ColFind (value, LowField, HighField) 

Both LowField and HighField must be in the same table. This 
table is scanned for a column with the value 'value' between 
the two fields. The primfive is normally used to locate the 
CardTable Column for a card. The result variable is set to 

0 if no match is found, or 1 if a match is found. 

ColSelect Primitive 

ColSelect ( Column , Table , Reset) 

Selects the relevant column of the table indicated. 
Column 

The column to use. The transaction table has only one 
column, the totals table has ten. The other tables 
(issuers, aquirers etc have one colum for each record in the 
corresponding initialisation data base 

Table 

For comparability, 0 (zero) selects the totals table. The 
tables are as follows 

1 Transaction 
2Totais 
31ssuers 
4Acquirers 
SCard Ranges 

Reset 

If reset is 1 then all fields in the column are reset. 
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CommStat Primitive 

CommState (port ^ value, field) 
5 port indicates the port to be tested 

value indicates a value to compare and set the status 
accordingly. 

field (optional) indicates a field to store ComsState Value. 
This function reads the state of the port store the value in 
10 field (if specified) and sets the current function result 
status to true if the value matches "value". 

Date Primitive 

Date(commdnd , date-field , time-field) 

15 

IRead system date into date field and time field 
2Set system date from date field and time field 
see also 

2 0 Dates and Times 

Dates & Times are special data types both are stored as 
special numbers, 

25 Date Fields 

A Date field is a two byte number, representing a date since 
lJanl940 to lJan2110. Subtracting two dates reveals the 
number of days between the dates, dividing by 7 reveals the 
30 day of the week (Monday =0, Tuesday = 1 etc). 

When moving to or from a text field a date is converted to a 
text format of DDMMYY. If a format is used this may be 
converted to DD/MM/YY by using a currency symbol of / in the 
35 format. The text format of a date may be either 6 or 8 
bytes long- showing the year as 2 or 4 digits. 
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Date Fields only contain valid dates. Since every date is 
stored as a day number, the storing the string 32/01/1980 
will give is the acutal date 01 /Ol /I 980. If data is 
5 entered directly into date fields, then dates are corrected 
in this manner automatically. If you wish to check the was 
entered correctly, then enter the data to a text field, then 
move the value to the date and check it is equal to the 
string. 
10 e . g 

Repeat 



15 The above example will continue to ask for a date until a 
valid date is entered. 
Time Fields 

Time fields may be either two or three bytes representing 
20 either the time of day to 2 seconds (two bytes) or 1 /I 00 
of a second (three bytes) accuracy. 

Moving a time to a 2 byte integer gives the niamber of two 
second periods elapsed this day. Moving to a 1 byte integer 
25 extracs the 1 /I 00s second fraction (up to 199) 

Moving to a value or larger integer extracts the total 
number of tics (1 /I 00s sec) which have occurred prior to 
the time. 

30 

Moving a time to of from a text field results in either 
HHMIVISSFF when moving to a 8 or more byte field and HHMMSS 
when moving to/from a six byte field, 

35 This text value may be formated with a format to give 
HH:MM:SS . FF 



Print (GetDdte, O) 



ActualDate := TextDate 



Until ActualDate == TextDate 
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25 



30 



Moving values between data and time fields and other numeric 
types results occurs without conversion. Moving to and from 
text values results in conversion. See specie entries for 
conversion details 

Dial Primitive 

Dial (phone numberphone number) 

The numbers specified must be fields. Immediately following 
each number field in the data dictionary must be a a timeout 
field then a retry field and then a mode field. The 
upstream prot is implied. 

Do Primitive 

Do (Function) 

also known as 

DoFunc (Function) 

This primitive is used to activate another script function 
as a subroutine call 

Event Primitive 

Event ( Function, system event) 

Sets the specified fuction to be actived whenerver the event 
occurs 

Exit Primitive 
Exit (Now?, Value) 

This primitive is used to set the return value of the 
current function, and optionally, exit immediately. 
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30 



The 'Value' is stored in the Calculation Result, which will 
be regarded by any calling function as a result. 

If 'Now" is true (is 1) exit will be immediate, otherwise 
the exit value will be established. 

Func Number Primitive 

Function#f f ieldlnumber , bad number function) 

Execute the function with the assigned function#. Typically 
this primitive will be used by a user function set to be 
activated by a Hot Key on the target device labeled "Fn" or 
"Function" or similar. Such a user function would prompt 
for a number and then call this primitive (Function#) with 
that number as a parameter. 
See Function Activation. 

The "Bad - Number - Function" is a function in the script to 
be executed if the no function matching the first paramter 
exists . 

This is used to implement niomber functions- for example 
clearing memory might be function 1055. The user presses 
the "Function'* hot key, then enters 1055 to execute the 
function . 

To achieve this 

la function containing this primitive should created and set 
up under function activation to have the appropriate key 
code . 

2A function containing the appropirate action for the 
numbered function should be created and set up under 
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function activation to have the approiate function number 

The function number also returns the logical result of the 
request to call the numbered function, i.e false if no 
5 function exists, otherwise true. 

If Else End Primitives 

If 

10 

The next primitive is executed. If true then all primitives 
between the if and the else are executed. If false all 
primitives between the Else and End are executed. If 
nothing is required between for false then Else may be 
15 ommited. 

If ! (if with <not?> parameter) 

Else 

20 

Optional in an If see above. 
End 

2 5 Marks the end of an If or While. See While End 

KeyBd Primitive 

KeyBd(mode) - (O = off / I = on) 

30 

Upon entering idle state, the action of the keyboard is 
determined by the last KeyBd command. The keyboard (except 
cancel) will be ignored if off was specified. 

3 5 MAC Primitive 

mac (key, mode, message, field) 
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All targets must support the storing and use of 4 64 bit 
keys . 



Calculates a mac of the ' message ' and stores the value in 
the' field' specif ied. Uses the' key' specified- If 
the 'message' is 8 bytes in lenght only (or less) then a 
single DES encription only results. 



Stores the specied key into secure memory from 'field' 
Mod 

Mod (Value, Divisor) 

The value "value" id divided by the divisor, and the 
remainder is the result . 

e.g.- the following example would set the Data Field 
"Remainder" to 4. (25 divided by 7 has a remainder of 4. 

Mod(25,7) 

=> Remainder 

Pin Primitive 

pin (field) 

Retrieves pin block from pinpad. Not supported on all 
cardscript devices 

Print ( Display/Report, Part) 
Form 



mode I 
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The Display/Report may be selected from the list box- or 
alternatively by selecting Field- >Value [X] taken from a 
field in the data base, 

5 

Part 



Values - 0 = all, 1 = pre print/header, 2 = body, 3 = post 
print/ footer 

10 see Forms -end of Header/PrePrintt & Start of Footer/Post 
Print 



Action 



15 The selected section (or all) of the display is displayed 
or, in the case of a report, printed. 

With displays, any input fields will be accepted, however 
the Show Primitive is recommended for input operations 

20 

ProcDown Primitive 



Procdown (protocol, port) 



25 The specified protocol is started on the port specified. 

This function is normally used for downstream protocols such 
as an ECR- This function is intended for more advanced 
users and the protocol must specify its own success and fail 
functions . 

30 

Protocol Primitive 



Prot (protocol. Function 1, Function 2) 



35 The specified protocol is started on the bank corns 

(upstream) port. The current function execution continues. 
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KeyBd( Off ) is set (it may be overridden) . If the protocol 
returns a value of zero. Function 1 will execute, if any 
other value is return Function 2 will execute. (A KeyBd(On) 
will automatically happen before either function. 

5 

Range Primitive 
Range (f ield,Min,Max) 

Returns true if the value specified is >= min and <= max 
10 value 

Repeat /Until Primitives 

Repeat 

15 

Repeat sets the execution point for a following until 

Until (Case) Cases are 0 = False, 1= True 

2 0 Executes the next primitive and if the result agrees with 

Case then the Repeats everything after the repeat primitive. 

Report ( Form, Function) 
Action 

25 

First prints any pre print or header from "Form". Then for 
each transaction in the batch calls "Function" and prints 
the details section of "Form". After cycling throughout the 
batch, then prints any post print data from "Form". 

30 

Form 

The Display/Report may be selected from the list box- or 
alternatively by selecting Field- >Value [X] taken from a 
35 field in the data base. 
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10 



15 



20 



25 



30 



Function 

A function to be executed before each detail section is 
printed. For any transaction in the batch for which the 
function returns FALSE will be skipped. 

Restore Primitive 

Restore (layout/ field, secondary field) 

This primitive is used to retrieve information from the 
Batch Area. 



This optional ("none" is permitted) parameter specifies 
which transaction layouts are considered for retreival. 

WARNING! All records searched using a field other than 
RECNUM are actually retreived, changing the contents of the 
data fields in their layout. Using a value of "none" may 
have side effects! 



The primary search field. Searching will advance throught 
the Batch Area until a match is found. 

Secondary Field 

an optional (Use RECNUM for "none") secondary search field. 

Rom Function Primitive 
Rom ( valuelf ield/ Message) 

Generally the parameter passed is passed directly though to 
the bios. The following values are assigned for 
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portability. The message parameter is ignored unless 
otherwise stated. 

IGo to ROM mode. 

5 

2Erase memory and return to Rom 

3Start TIVIS download (from ROM mode) . 

10 4Store Rom Params . 

Uses Message and returns Success status. 
See ROM SETTINGS. 

51-oad Rom Params . 
15 Uses Message and returns Success status. 
See ROM SETTINGS. 

6Activate Rom Edit. 

Returns Success status. See ROM SETTINGS 
20 see Also 

ROM SETTINGS 

What are ROM SETTINGS 

Sub Heading 

25 

Normally target devices store programs in RAM memory^ and 
are capable of loading these programs over the telephone 
Network. In order to acheive remote loading the device must 
store telephone number and other details required. The 
30 device must have a method of loading and/or editing these 
details . 

Methods vary from device to device with information normally 
being obtained from the keyboard^ a smart or magnetic card 
35 or some combination. Obviosly the information must be able 
to be set prior to the application loading. 
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Communication Between Rom & CardScript 

Two possible reasons for CardScript to interact with the ROM 
Settings arise. 

1 The parameters may need to changed in a device already 
loaded with the CardScript application. 

2A CardScript application may need access to the ROM Setting 
values . 

Edit Rom Settings - Rom Function 6. 

The desired method of allowing change to the settings is to 
use this function primitive call . ( see Rom Function 
Primitive.) This primitive may not be supported by all 
Drivers and (check with the driver provider) but provides 
the only device independent method of implimenting the 
function. An advantage of this function is the operator 
sees the same interface as when configuring the terminal 
prior to loading CardScript. 

Load Rom Settings -Rom Function 4 . 

This function is used to obtain the ROM settings in a 
Script . 

Store Rom Settings -Rom Function 5. 

A Script Program may load the Rom Settings with Function 4, 
allow editing of values and use this function to store the 
settings. It is recommened to use function 6 (edit) in 
place of this proceedure where available as this mechanism 
allow changing of device specific settings. 
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To provide a much device indepenance as possible using 
functions 4 and 5 CardScript defines a standard 
Communications Buffer Layout with a private area at the end. 
All Fields are ASCII. 

The first three fields are assumed to be used for all 
communcications , 2 bytes connection mode. Lan Leased Line 
etc 4 bytes station/Lan Address 
8 bytes telephone prefix - eg "9," 

Field 1 16 Bytes Terminal ID. The ID as seen by the 
software management system and not 

necessarily other systems. 

8 bytes terminal type 

24 bytes phone number 
0 

24 bytes connection string 

Save Primitve 

Save (transaction layout) 

5 

Saves the current transaction to the batch using the layout 
specified, A new Transaction Index is generated according 
to the method speified by the last Txnidx: Primitive, with 
the new index stored int field(0,0) RECNUM. For details on 
0 RECNUM see Reserved Data Dictionay Settings. 

The number of transactions (of the selected layout) which 
can be stored is returned. If zero is returned, then the 
save could not work! If 1 (one) is returned then no more 
5 may be saved. If two is returned then only one more may be 
saved, etc. 
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Store Primitive 

Store (of f set,messageLayout) 

5 The store primitve stores the last received message, 

starting at byte <offset>, using the specified message 
layout. The function result status is set by the operation. 
(Set to FALSE if the store did not match) . 

10 Tots Primitive 

Tots ( valuer Field) 

Selects the relevant totals column. 

15 

This primitive has been replaced by the ColSelect primitive. 
Old programs are automatically upgraded, since parameter 2 
or LineTble, when zero, will select the totals table 

2 0 Txnidx Primitive. Set Transaction Index. 

Txnldx (Fieldl, Field2,mode) 

Fieldl is optional. If include the first two digits of the 
25 Index are set from this field. 

Field2 specifies the the main field on which the Index is 
based. By default this is the ROC field. 

30 the mode specifies how cardscript increments the Txn Idx. 
0=add 1 
l=Amex Style 

2=None, Incrimented by script. 

35 This function would normally only ever be used in a start up 
function- The calculated value is always stored in the ROC 
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field. 

User Function Primitive 

5 The user function primitive is used to call any of a range 
of functions. The functions call by user function are NOT 
standard. 

Primitive - Extensions 

10 

It is possible to extend the primitives available to 
cardscript. The extensions take to form of a block of 'C 
code loaded with the Script. 'C code, of course, has the 
restriction of being non portable. 

15 

The existence of these extensions is to allow extensions to 
a set of primitives to be tested without changing the core 
driver. Any extentions initialy tested by this means must 
be added to the set of primitives in a new release, 
20 otherwise the code calling them will never be portable. 

Wait Primitive 

wait (minutes, lOOmsecs) 

25 

The current function pauses for then number of minutes + 1 
Oths of seconds specified. A delay of up to 1000 minutes 
(over sixteen hours is possible) and as small as 1/10 of a 
second. 

30 

While / End Primitives 

While (Case) Cases are 0 = False, 1= True 

35 The next primitive is executed. If the result matches Case 
then all primitives between the While and the End are 
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executed, then we come back again to the While. If the 
result does not match Case then execution continues with the 
primitive following the End. 



Marks the end of an If or While. See also If End 

For specific categories of primitives see 

10 Communications Primitives 
Data Entry Primitives 
Displaying and Printing 

For information on configuring CardScript for target device 
15 function primitives (advanced users only) see 

Configure Function Primitives 

For advanced users only! ! 



Usage - Name Changes 

Changing the name of a primitive or a primitive parameter 
will cause all scripts using the name change to be 
25 automatically updated. Both this type of change and any 
chages to the "infix" status of a function will have no 
affect on the driver and scripts will function without 
further change. 

30 Usage -Adding, Deleteing, Changing Parameter Types 

Parameter Settings 

Each function parameter has the following possible 
35 catagories 

lA Field from the data Dictionary 



5 



End 



20 
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2Numeric Value -Which may be displayed as an index to a file 
3A String 

Any parameter may legally accept any combination of 
categories 

5 

Layouts 

Cardscript allows you to graphically enter your layout 
specifications. For details on Reciepts, 'Reports, 
10 Displays, Messages, Protocols, and Transactions see 
Layouts Menu 

Layouts are the main engine of any application. Although 
all layouts must bee brought into operation by functions, 
15 layouts also in turn launch functions and other layouts. 

Form layouts, message layouts, and transaction layouts are 
similar in operation. All three are an arrangement of 
fields and strings called a field panel. For details see 

20 

Field Panels 

All field Panels (Displays/receipts, messages and 
transactions) have a Panel Control box in common. The 
25 selection in the Panel Control box selects the action to 
take place when the left mouse button is clicked over the 
panel . 

Additional controls are present of some panels, however, 
this box always contains 

30 

An add field -control with field edit box and pallete 
selector 

35 Clicking on the p'a'nel when [add] is selected adds a new 
field as displayed in the edit box 



SUBSTITUTE SHEET (RULE 26) 





wo 98/41918 



PCT/AU98/00173 



. - 84 - 



Before - clicking on the edit box to set the field to be 
added, select the approriate type of item in the "from 
pallete" drop down list box 

5 

Clicking on the edit box brings up either the Select Field 
Dialog or the Enter String Dialog, in accordance with the 
pallete selector 

10 A dealt field control 

Select [delete] and then click on the appropriate field 

A select field Control 

15 

Select [delete] and then click on the appropriate field 
Field Edditing 
20 To edit any field, double click on the field 
Forms (Displays and Reports) 

see also Field Panel, Print Primitive, Show Primitive and 
2 5 Report Primitive 

The Screen is Divided into four sections 

The Form (Display/Report) Panel 

30 The panel is a Field Panel where the location of the of each 
field corresponds to the place 

actual data will appear on the display/printer 
The Dashed Boundary 

35 

Depending on the Display/Report type, a dashed line will 
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appear showing the limits of the display or printer. This 
boundary is dravsm in accordance with the settings in the 
Tables/System menu and can be changed at any time. 

5 Form Name 

The display report name is used for reference to this screen 
and should contain a 
meaningful name • 

10 Panel Control 

In addition to the panel controls discussed in Field Panel, 
two additional controls are present. 

15 <<End of Pre Print 

Pre-Print fields appear with a grey background 

Select this item and click on the field after the end of the 

header section of the report. 

20 

Used in reports , the header section is printed once at the 
beginning of the report. The sections following the header 
will be printed once for each transaction in the batch, see 
Report Function for further details 

25 

Used in receipts (see Print Function for futher details) 
used to divide the receipt inot sections 

Start of post print 

30 

Post-Print fields appear with a grey background, and can 
only be distinguished from Pre-Print fields if there are 
fields in between. (As would normally be the case.) 

35 Select this item and click on the first field of the post 
print section of the report - 
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10 



15 



20 



25 



30 



Used in reports , the Post-Print section is printed once at 
the end of the report, see Report Function for further 
details 

Display/Report Type 
The types are 

Display - layout will always appear on the display, and in 
scribe will have a border reflecting display width and 
number of lines 

Secure Display - reserved for future use 

Printout - layout will always appear on the printer, and in 
scribe will have a border reflecting printer width 

Soft Keys 

The Soft Keys Button allows selection oof a soft key set. 
see 

Messages 
Output messages 

A messages buffer is built from fields in the data 
dictionary, and from strings in much the same way a printout 
is build. However, in messages, all data may be represented 
in forms other than ASCII, (see "the message engine". 
Formats may be used to specify data within the selected 
representation . 

Input Messages 
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10 



15 



20 



25 



30 



Messages are also used to specifiy how data is transfered 
from a received buffer and stored in data fields, 
see also 

The Message Engine (Processor) 

The message engine is used both to transfer information both 
from data fields inot a message buffer, and from a message 
buffer to data fields 

see also 

Message Data Mapping 

Every field in a message buffer is converted from the type 
in the data field, to the representation of in the message 
buffer. For "Forms" all data in the buffer is Ascii, but in 
other messages the data may be any of the following 

Ascii 

Ascii Representation 
Strings and Text Fields 

Strings & text fields are simply copied. If the source is 
shorter then the destination, spaces are used for padding 

Integer 

Integer to Asch 

For one & two byte integers, the binary value is converted 
to its string equivalent and then formated acording to any 
format specified. Larger inger conversion may appear in a 
later release 
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Ascii to Integer 

Again limited to 1 and two byte integers, the value of the 
5 text is calcuated and stored in the integer. 

Amount 

As for integer. 

10 

Dates 

Dates are converted to either DDMMYY or DDMMYYYY if the 
Ascii field is longer than 7. Formating is applied on 
15 convesion to ASCII only. 

Times 

Times are converted to either HHMMSS or HHMMSSFF (where FF 
20 is the fractions of a second in hundredths) if the Ascii 

field is longer than 7. Formating is applied on convesion to 
ASCII only. 

Hex 

25 

Hex Represntation 
Amounts 

30 To Hex: The data is coverted to a BCD string and then 
expaned 

Integers 

35 The binary value is conveted directly to Hex. eg a one byte 
value set to 35decimal (23 hex) would be conveted to two 
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bytes - characters' (Ox32) and '3' (0x33) representing the 
hex value 23. 

Binary 

5 

Binary Represnation 
Integer 

Binary representation of integers is High Byte . • . . Low 
10 Byte. As a binary value. No Actual conversion takes place 



Binary respesnation of Text is to assume the text is a 
15 hexadecimal string and convert this to binary. To get an 
exact copy of the string use Text Representation. 



2 0 BCD Representation. 

The Data is converted to the BCD data type. 
Formats 

25 

Formats are used for specifying exactly how data will be 
represented 

Justification 

30 

Any time the data lenght is less than the field width, the 
justification will be used to decide where the data is 
placed. 

35 Allowed Characters 



Text 



BCD 
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Specif iies the type ot characters allowed during input. 

Minimum Characters 

5 Specifies the minimum characters allowed for entry to a 
field. 

Maximum Characters 

10 Specifies the maximum characters allowed for data entry, and 
the maximum displayed characters on output. 

Input Window 

15 A non-zero value in this field specifies input will occur 

within a window. e,g A 24 character text field may be input 
using a 1 0 character window because of limited display 
space. Note that only ten characters of the input would 
then be visible at any one time. 

20 

Input Validation 

A function may be specified here to valid input using this 
format. The validation function may store the current input 
25 using the ->(res) primitive. See also the Console Primitive 
command 4 . 

Note that an input validation function MUST NOT do any 
displays, as the current display would be overwritten. 

30 

Suppress leading zeros 

Check here to suppress leading zeros in numeric fields, or 
leading spaces in text fields 



35 



Decimal places 
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Select the appropriate number of places, and the character 
to use as the decimal indicator- Selecting the decimal 
(from'.' or',') also determines the character for thousands 
5 separation. (The opposite character to the decimal is used 
for thousands . 

Check the box to require keying of the decimal indicator 
during input. If this box is left unchecked, data 1. 00 (, 
0 as decimal) would be input as 1 00, cash register style. 

Auto OK 

If this box is checked, when the maximum characters are 
5 entered, input will be concluded. 

Thousands 

The thousands separator (as determined under decimal places) 
0 will be automatically inserted. 

Password Mode 

The first character of the currency symbol will be be 
5 displayed in each position, in place of the actual character 
entered. 

Currency Symbol 

0 Specify if the currency symbol is to be displayed- One or 
two characters may be entered. If the value is two digits, 
the digits are legal hex digits then these will specify a 
the character, e.g. 41 would specify the characters', as 
would a single A character. 

5 

This field as has other uses. 
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The separator for date & time fields is the first character - 
For time fields the second character is used to separater 
the hundreths of seconds when displayed 

5 

Lenght Indicator 

In additon to the data, the data length is to be included. 
The number of digits to use may be 1,2 or 3. The lenght may 
0 be before (pre) the data or trailing (post) . As an 

alternative to a numeric length specification the currency 
symbol may be used to indicate the end of a variable lenght 
field 
e.g. 

5 lenght as 1 

- Sabcde is a five character field 
lenght as 2 

- 05abcde is the same field 

currency symbol as':' and use currency selected 
0 abode: is the same field again 

Pad BCF with F 

Check here for BCD fields of odd lenght to be filled with a 
trailing F nibble. If unchecked a leading zero nibble would 
5 be used. 

Transactions 

Two other layouts types are also available 

0 

Bitmaps 
Protocols 

5 Protocols describe message flow both from and to the target 
device. The top line specifies outgoing messages and the 
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other lines display possible incoming results. A protocol 
consists of lines and sections. 



Request Line 

5 

At the start of each section is a line 1 (optional for the 
first section) which describes the outgoing message. This 
is the request line. 



10 Response Lines 



Lines 2, 3 and above define actions to be taken when a 
response is received. These are the response lines. 
A response may be a data received or a time out. When a 
15 timout occurs the first line with a timeout will be 

selected, any other line with a timeout will never be used. 
When data is received, all lines beginning with a message 
are tested to see if received message matches the 
requirements . 

20 The first item on each response line must be either a 
message or a timeout - 
Protocol Screen Editing 



Adding Entries 

25 

Select the desired item to add, then click on the display at 
the desired location 



Splitting Sections 

30 

A section may be split on line 1. Click below the line 
slightly to the left of the field to become part of the 
second section. 

3 5 Adding to a Line 
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When adding fields click on the field that will be after the 
new field. To add to the end of a line click about 3 spaces 
beyond the end of the line. Always click on the desired 
line , 

5 

Inserting a line. 

Click where the new line should start 

10 Retrys/Skips 

After entering a Retry, the retyr field will be selected. 

Or you can select the retry later. Once a retry is selected 

the <<set retry>> and <<set skip>> commands can be used to 

15 set the points where execution should move in the event of 
either a retry or the retry count being exceeded. Note, 
retry can only move back and skip can only move forward. 
For those with color displays, the retry arrow is green and 
the skip arrow is drawn as red. You can't put a retry/skip 

20 on line one. 

Identifying Input Messages 

The first field of each input line is used to select when 
25 the input is appropriate. The following possibilites are 
catered for 

Control 

30 The input line is selected when the a message begins with 
the specified character 

Message 

35 The incomming message is matched against the message 
specified. 
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Timeout 



10 



15 



20 



25 



30 



A timeout line will automatically be selected in response to 
an incoming timeout. 

Function 

If the function returns true the message is matched. The 
Store Function. 

Functions Launced By Protocols 

Within protocols it is possible to launch functions for 
various reasons, particularly to store complex messages and 
select options. 

Such functions should NOT halt operation, either by WAIT ( or 
for input or any other event. Should a function attempt to 
do so, subsequent functions launched from the protocol, 
including the "good" and "bad" functions, will execute 
before the function resumes. 

Delay any inputs until the good or bad functions at protocol 
end. If you are an expert user and must do an input, make 
it the last command in the function and exersize caution. 

Repeated Messages 

A protocol may involve repeated messages. That is, after 
storing the data from an input message, another similar 
message will be received. 

Fixed number of repeat messages 

If the number of times a message is to be received is fixed 
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then the following approch may be used 
<Msg><Retry (nn) > 
5 Where nn is then number of messages expected 
Variable number of repeat messages 

If the number of times the message will be repeated will 
10 vary, i.e a flag in the message indicates that a repeat 
message will follow, then the following technique is 
recommended . 

use an input line with <Function><Retry (O) > 

15 

This will cause a loop whilst the function returns true. 
From the function, use the store primitive to save the data 
and return true if another message is expected 

2 0 Layout Primitives 

Layouts use the following elements as building blocks 

Putting it all together 

25 

Build Menu 

Build Target Group Files 
30 Builds the font and conf files ready for program execution 
Build Script as Fragment 

Builds a reduced script for loading either onto a smart or 
35 through the communciations network, for describing a 

particular operation which may be chenged without loading a 
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new program. 

Build Secure Prompts 

5 Builds the list of secure displays and associated strings 
for loading into a secure display. 

Run Simulation of Build 

10 Activates the terminal simulator program 

see also 

Files Produced By Build 

15 

Font Files 

XXX is the niomber of the font. Currently always zero 

2 0 fontlxxx.bll 

Characters O. . 127. Bytes are dots across. First byte is 
top row. If more than 8 dots across, then the next byte 
continues the dots 

25 

fonthxxx.bll 

Characters 128.255, using the same format as theTfile 

30 fontdxxx.bll 

Characters O. . 1 28. Bytes are up and down. First dot is 
top left (bit 0 of byte 1) then dots down the character. 

35 fontuxxx.bll 
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Script Fragrments 

Script fragments are small scripts (usually < 256 bytes) 
built separately to a main program. Theses scripts may then 
5 be loaded into the terminal (either from a smart card or as 
part of a message) in order to specify operation of 
changeable program feature 

Examples of Fragments 
10 A Fragment for User Authentif ication 

A Smart Card could contain a program fragment specifying how 
the terminal should check the user of the card is the real 
owner. Then cards may be issued with varied scripts such as 

15 

Input Sc Check PIN 

Print A Slip and request a signature Do nothing- no check 

20 A fragment for communications protocol 

A server could have a list of communications protocols of 
various networks. Then the terminal could dial the server 
and request the relevant fragment for a particular 
25 network (either because the terminal has no information on 

the network - or the exsting protocol no longer functions) , 
allowing the terminal to operate on a new or changed network 
with obtaining a complete new application - 

30 Menus 

File Menu 
Configure Menu 

35 The configure menu is greyed on standard level Scribe. The 
functions available are for the use of advanced users only. 
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Generally within an Organisation using CardScript either one 
master user will be placed in charge of setting 
configurations or configurations will be set by an external 
consultant . 

5 

The configuration options are 

Configure Simulation 

10 Host Comms 

Select a comm port for the simulator to use for modem 
communications. If none are available select "none" . 
Selecting "none" precludes testing comms facilities 

15 

Terminal Group 

The Build process creates serveral build files one for each 
terminal group. The setting chosen here determines which 
20 build file will be used for simulation. 

Cards 

The simulator does not use a real card reader. Instead it 
25 supplies card data from this table. Enter card data as 
required for up to eight test cards. 

To provide the simulator with information on this PC and to 
create test "Cards". 

30 Configure Targets 

A number of target machines may be described to the 
cardscript system. The information about the target 
machines is used in various places throughout the scribe 
35 system to present information in a manner appropriate to a 
currently selected "target" machine, see System Record 



SUBSTTTUTE SHEET (RULE 26) 




wo 98/41918 PCT/AU98/00173 

- 100 - 

information for setting a Current target. 
Object types 

5 The target machine is descibed by arranging an number of 
"objects" on this panel. Their is one of each of the 
display/ printer, and reader objects, and as many button 
objects as are appropriate. 

10 The display object is used to specify the display 

configuration in lines and columns. This object should be 
dragged to an approriate loaction in the window. 

The printer object is used to specify the print width 
15 columns. This object should be dragged to an approriate 

loaction in the window. The number of lines setting bears 
no relation to the number of lines on a printer page, this 
field determines how many lines will be available for 
viewing during simulation. 

20 

The reader object is used to describe which area of the 
window will be used to display buttons for simuation of a 
card reader. This area bears no relationship th an actual 
card reader. Drag this object to an otherwise unused area 
2 5 of the window . 

TVny number of button objects. The object correspone to the 
push buttons on the target device. Five different button 
styles are available. Configure these styles as required. 
30 When a style is changed, all buttons of that style will 

change in appearance. Keycodes returned should match those 
returned by the actual terminal BIOS. Use the KeVMap 
Primitive to force the map these codes to the codes required 
by the actual application. 

35 

For describing the various hardware platforms to the system 
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For designing Tables Screen Layouts and Contents used on the 
PC with Scribe 

5 For designing the Data Dictionary used in the Target Device 

For Specifing the functions available within the target 
device . 

0 Reference 

Index 
Glossary 

5 # 

"->" (goes to) primitive: <goes to primitive> 
"KeyBd" : <KeyBd Primitive> 
"refer" : <ColSelect Primitive> 

"target": the PC, EFTPOS terminal , PiNpad or cash register 
0 which will be used to run the 
developed application. 
->(res) : <result goes to primitive> 
B 

Batch Area: Storage area of memory. Used for storing 
5 transactions and any other miscelanous data. Also may be 
thought of as file storage. 

bitnumbering: <Bit Numbering> 
C 

0 CardEntryMode : <Card Entry Mode> 
ColSelect primitive: 

Commands for Memory Cards: <Commands For Memory Cards> 

Console Primitive: <Console Primitive> 

D 

5 Data Dictionary Field Atributes: <Data Dictionary Field 
Attributes> 
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Date & Time Fields: <Dates and Times> 
E 

eserved data dictionary fields: 
F 

5 Field Panel: <Field Panels> 

Forms -end of Header/PrePrinf t & Start of Footer/Post Print: 
<Forms> 

Function Action: <Function Action> 
Function Actions: <Function Actions. > 
10 Function Primitive Catagories: <Function Primitive 
Catagories . > 

Function Primitives: <Function Primitives> 
H 

HEX: . Digits 0,.9 and A. .F 
15 I 

Initial Data Field Atributes . : <Initial Data Field 

Attributes> 

K 

KeyMap Primitive: <KeyMap Primitve> 
20 P 

PFIELD: special field for use on Forms. In place of this 
field a supplied parameter field will 
be displayed 

Print Primitive: <Print Primitive> 
25 PSTRING: special field for use on Forms. In place of this 
field a supplied parameter string will be displayed. 
R 

RAD: Application Development (especially used with ' tool ') The 
process of defining a program in a very short time by 
30 starting the progfram definition wtih the user interface. 
Report Primitive: <Report Primitive> 
Reserved Data Dictionary Settings: 

Reserved Data Dictionay Settings: <Reseved Data Dictionary 
Settings> 
35 ROM SETTINGS: <ROM SETTINGS> 
S 
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Show Primitive: <Show Priinitive> 

Smart Card Type Code: <Sinart Card Type Codes> 

System Table Settings: <System Table Settings> 

T 

5 Txnldx Primitive: <Txnldx Primitive> 
W 

Windows: popular operating system for PCs. based on an 
event driven architecture. 
APPENDIX B 

10 

Bios Objectives 

The objective of the Cardsoft BIOS is to make all devices 
15 used for running Point of Sale software compatible with 
CardScript programs . 

Bios Usage 

20 The Cardsoft BIOS specification is designed to allow the 
creation of portable programs for Payment Terminals- Any 
given implementation of the BIOS will encompass its own 
"look and feel" which, in turn, is imparted to applications 
using the system. This is possible since the BIOS specifies 

25 what must be achieved by low level functions, rather that 
the manner of achievement. This means that not all 
implementations of the BIOS are equivalent and there is 
scope for vastly different performance and operational 
convenience whilst still maintaining BIOS compatibility. 

30 As an example, the BIOS itself does not specify how such 

things as how cursors and editing functions are implemented, 
there is simply a call specifying display this field and 
allow it to be edited. Thus the field editing rules are 
determined by the individual BIOS implementation. One brand 

35 of equipment over type may be standard, on another insert 
may be the default. 
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This leaves individual implimentors with the ability for 
creativity and a framework which allows for the performance 
and convenience of their programmers to be a product 
advantage . 

5 Also supplied in addition to the core BIOS are some 

implementation routines. These are supplied in source code 
as a starting point for actual implementation. However the 
code in these routines is not applicable to all hardware 
configurations and would expect over time to be modified in 

10 any given implementation. 

The BIOS described in this manual represent the interface 
between Cardsoft EFT applications (including the driver for 
CardScript) and an EFT terminal, however the specification 
is general purpose in nature and may in future be used to 

15 support other systems. This manual assumes CardScript is to 
be supported and is geared to assist in achieving this goal. 
In addition to the functionality described here the EFT 
device must have its own "bootstrap" 

system. Where Cardsoft applications are being added to 
2 0 existing products a software module which interfaces between 
routines described here and the existing driver software can 
easily be produced. 

This BIOS specification remains the property of Cardsoft. 

25 Utilising Existing Operating Systems 

When first adding CardScript to a device, some level of BIOS 
or operating system will normally be already in place. In 
many cases it is desirable to add CardScript to devices 

30 originally developed years prior with well tested hardware 

device drivers. In these instances the BIOS will constitute 
an interface between the existing operating system and the 
CardScript driver. The BIOS may then be linked with the 
Driver and the combined application loaded as one 

35 conventional application. 

The BIOS is designed to be able to be placed as a layer 
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above any pre-existing operating system, and be loaded 
together with the Driver program an one application to 
devices installed in the field. 

5 New Products 

In the icase of new products, created for use with 
CardScript, a purpose build BIOS will minimise memory 
requirements and speed time to market. 
10 Steps To Implementation 

The steps in implementing the Cardsoft BIOS are as follows. 
Check the BIOS library supplied with this manual is correct 
for your microprocessor development tools. Other versions 
15 of this library for other development environments may be 
obtained from Cardsoft, 

Choose appropriate optional code. In order to simplify 
implementation of the BIOS sample code is supplied for some 
typical hardware configurations types providing higher level 
20 functionality and simplifying installation. It is 

recommended to make use of this software initially, and 
replace code as desired once the system is operation on the 
target hardware. Use supplied outline "main.c" and compile 
& link. 

25 Add routines to eliminate unresolved externals. Use empty 
routines supplied for routines to be supplied later. It is 
recommended to initially include real keyboard and display 
routines and then add others. 

30 Concepts 

Event Driven Structure 

Applications constructed to run on the Cardsoft BIOS must be 
event driven. This allows the BIOS or operating system to 
35 have control during idle periods. When an input event 

occurs, the application is called to process the input, and 
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then returns to the BIOS / operating system. The 
application sets which routine will handle each message and 
what messages are enabled. 

This event driven structure allows the BIOS to operate as an 
5 interface layer to event driven operating systems without 
problems. Where the underlying structure is not event 
driven This enables the BIOS functionality to be matched by 
either low level BIOS code or by a high level operating 
systems ensuring maximum portability of Cardsoft 

10 application, and enabling sophisticated underlying 

structures to be utilised where present. The event driven 
structure of the svstem means that applications do not 
contain a "main" procedure. Applications have an init- 
application( routine which sets up a table of routines 

15 addresses to bo called in the case of external events 
occurring. 

Callbacks 

2 0 Callback Control - Input 

The BIOS must maintain a callback address table with four 
entries for each input/output file. Associated with each 
entry in the table is an enable status. When the 
corresponding event occurs a callback should be made using 

2 5 the address from the table. Each callback contains an 

optional Code and Message (see below) . The BIOS should not 
issue a second callback while another callback is in 
progress. This can lead to race conditions. 

30 Output 

For porting the Cardsoft Bios to a new machine see 
Low Level Interface 

35 

The low level interface represents the routines that must be 
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custom written when porting CardScript to a new device. 
These routines assume that the standard Console module, or 
equivalent are used. Use of these modules eliminates most 
of the work in implimenting the Cardsoft Bios, but postpones 
5 fine tuning the Bios to make use of Specific hardware in the 
most efficient manner. 

Standard Modules 

10 The following modules irriDliment the high level interface 
console . c 
callback. c 
math . c 

To impliement the low level interface, a single module may 
15 be created interfacing the foiling routines to the actual 

hardware or existing drivers, the categories of routine are 

Low Level Display 
void dispbin (uchar ch) 

20 

Display characher ch at current cursor position and advance 
cursor one place 

void cleardisplay { ) 
25 void dispStr (uchar *str,int len) 

continuous dispbin for lenght of str. 

lenght of str is either len characters, or if len = -1, then 
str is null terminated. 



uchar dispScroll (uchar direction) 

Directions are 
1 left 
35 2right 
3up 



30 



SUBSTITUTE SHEET (RULE 26) 





wo 98/41918 



PCT/AU98/00173 



- 108 - 



4 down 



10 



15 



20 



25 



30 



Each call is a request to scroll one place in the specified 
direction. Thje result indicates the sucess of the request 
(1 = OK, 0 = can't do) 

Low Level Printer 

The only printer routine is low level, see 
Printer 

void prch(uchar ch) 

This routine simply prints the character "ch" on the printer 
device . 

Special codes are as follows 
OxA (10) end of line 

OxC (12) end of form. Feed I ines as required for tear off 
of receipt 

10 General Routines 

uchar sof tKeyBase (uchar select) 

By convention returns V for a paramter of 0, and 'a' for a 
paramter of 1. Change these to indicate actual key values 
for soft key sets 

buz 

void buz{int freq, int duration) 
Communications 

The following routines must have the code inserted to call 
the low level drivers correctly. 



SUBSTITUTE SHEET (RULE 26) 



wo 98/41918 



- 109 - 



PCT/AU98/00173 



All routines work with a comfile number. Number 0 is the 
default and is used for the modem. Number I should be the 
auxiliary com port, if present. Number 2 is the second 
5 auxiliary (again if present) etc. 

Sendcom_msg 

This routine sends block of characters to the specified 
0 port. If low level drivers (such as those used with HDLC) 
require the block at one time then you will need to call 
those drivers directly from here. If the target device 
supports only character mode communications, then the 
"sendcom" routine may be called once for each character. 

5 

void sendcom-msg (int comfile, uchar *buf , int countOfChars) 

{ 

} 

0 Sendcom 

A singe character is transfered to the specif ed port, 
/* individual corns character send routine */ 
void sendcom(int comfile, int ch) 
5 { 
} 

Dial 

0 This routine is used to start the dial process. "numl " is 
to be dialed "cntl times, then if this fails, "num2" is to 
be dialed "cnt2" times. "Mode" indicates the communction 
mode to be used. These paramters are under direct control 
of the application programmer, but by convention 

5 model=async, 2=HDLC 
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/•^ MODEM */ 

void dial {uchar *nuitil, uchar lenl,uchar cntl 
, uchar *num2, uchar len2/ uchar cnt2, uchar mode) 
{ 

5 } 

Hangup 

The equivalent of the ATH command on a hayes modem. 

10 

void hangup {) 

{ 

} 

txstate ( ) 

15 

uchar txstate () 

This return should return a status as follows 
0 = busy 
2 0 IReady 

2Reserved for errors, no currently used 

Real Time Clock 

25 The real time clock is red & set with the biosDateTime ( ) 
routine 

biosDateTime ( ) 

30 unsigned int biosDateTime ( command , buffer) 

Command (1 =read Dateltime,2 =set date & time from buffer 
Buffer DDMMYYYYHHMMSSFF 

35 TPDU - The smart card interface 
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uchar driveTPDU (uchar 11, uchar 12,uchar * Command, uchar 
*sendBuf , uchar *receiveBuf ) 

This routine impliments, both the Scribe TPDU and SmartCard 
5 primitives- To decide which is call is being made, the 
Command parameter must be tested. 
Command == NULL, SmartCard Primitive 

11, and 12 are the parmaters . Refer Scribe. hip for details 

10 

Command != NULL - TPDU primitive 

This a direct implementation of the scribe TPDU primitive, , 
with LI as the length of the sendbuffer, and L2 the length 
15 of the receive buffer. 

If LI is non zero, there is data to send to the card. If L2 
is non ZERO, then data from the card is required. 

20 Result 

Return zero, unless the function is used as the SmartCard 
Primitive, and a result is required. 

2 5 Timer 

Cardscript requires the target device to have a 
lOOmillisecond timer. This timer should may a call to the 
script routine "time - tick{)" 

30 

It is recommended not to make a call direct from the 
hardware timer interupt. This would result in actions 
launched by time tickO to execute with interrupts off, 
giving some very strange results. 
35 Instead set a flag in the interupt handler and have the 

event loop clear the flag and call time-tick () (if using an 
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interrupt handler) . 

The script driver includes the routine "start-bomb () " which 
may be called by the bios interface if required 

5 

The Font File 

The font file consists of sets of entries as follows 
1 Character code - 1 byte 
10 2Width - 1 byte 

31-leight - 1 byte 
4Bitmap 

The bitmap is arranged as follows 

15 For each row of height as many bytes as needed for the bits 
(1 for width <= 8, 2 for width <= 16 etc) . 

Left most bit in the MSB of the first byte. 

20 The file is appended with a block of three zero bytes. 
(Code, width, Height =0) and no bitmap. 

For fine tuning an operational Bios see 

25 BIOS Specification (High Level Interface) 

By Catagory Routines are:- 

Console (Display & Keyboard) 
30 Input 

Sequential (Non event driven) 

Since the non event driven machine must be made to appear 
event driven, the bios interface must include the main line 
35 and call the application to handle any events 
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Sample main ( ) 
{ 

init - hardwareO; perform any hardware specific 
initialisation */ 
5 init - applications 0 ; /* call to routine in module DRIVE */ 
for ( ; ; ) 
{ 

if (event) /* test for event*/ 
{ clear - event () ; /* clear event status */ 
10 handle-event {) */ call cardscript event handle - see 

list*/ 
} 



} 

15 } 

Events and Handlers 

The following list of events should be catered for 

20 

Events List 
Console 

If the high level console is used. Keyboard events are 
reduced to a single call-Process - 

25 

Process-key 

void process-key (uchar key-code) 

All that is required by the implimentor is to may key codes 
30 from the actual machine to the those to be seen by the 
cardscipt application . 

Please note that the application programmer has the ability 
to remap the keys sing cardscript. 

35 

Special Key Codes 



SUBSTITUTE SHEET (RULE 26) 



wo 98/41918 



- 114 - 



PCT/AU98/00173 



OxA "Enter" or "OK". (Completion of input) 
0x8 "Clr'or backspace 
OxlB Cancel 

5 

The only other console input is the magnetic card reader. 
Please use 

callback (Console, 3, <unused>, buffer, <unused>) ; 
0 (use 0 (zero) for unused parameters, 

or 

process-card (<unused>, buffer) 
Magnetic Card Read Buffer 

5 

The buffer may include any or all of the following sections. 
They must appear in order. 

Section I (optional) 
0 Identifier byte (001) 

Track 1 Data - all ascii values 

Track2 (optional) 
Identifier byte (002) 
5 Track 2 Data - all ascii values 

Track 3 (optional) 

Identifier byte (N03) 

Track 3 Data - all ascii values 

0 

End of data marker 
Identifier byte (0x0) 

System 

5 

System Events 
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10 



15 



20 



25 



30 



For each event, make a call to the routine 
void systemEvent (uchar event) 

Communications 

Comms Events 
Character comms 

callback (Port, 1, Character , NULL, O) 
Message based comms 

callback (port, 2, 0, Buf f erAddress •MessageLenght ) 
Dial or Tx Finished 

When any operation which made the communications port busy 

has finished, it should tell the script driver by the 

following call 

callback (port, 4, 0, NULL, 0) 

see also 

Event Driven Input 

Please consult Cardsoft for further information 

Structural 

Memory Management 

The MEMPTR type 
External Memofy 

Often target devices have 8 or 16 bit microprocessors which 
can address limited memory without the use of paging. To 
allow access to such memory, the concept of External Memory 
has been defined 
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It is not assumed that this external memory is directly 

addressable by the CPU, instead this memory is accessed only 
via the memory management functions . 

5 The script, the data dictionay fields, any optional fonts 
and the file storage area are all stored in "external" 
memory. These areas of external memory are allocated 
numbers as used in the getbase ( function, 

10 A type MEMPTR is used to address this external memory. In 
the include file custom. h the type MEMPTR must be defined. 
If has less than 64k: of memory allocated amongst the 
external memory areas MEMPTR could be defined as unsigned 
integer. If the memory is larger than this than MEMPTR will 

15 normally be defined as "long". 

Each block of external memory must APPEAR to be continuous. 
That is incrimenting a MEMPTR with the c operator must 
always generate a pointer to the next byte of the area, 

20 

The memormy management routines must map these virtual 
memory addresses in to real memory addresses, 

getbase (base) 

25 

The function getbase returns the virtual memory address of 
each of the following blocks of memory 

1 The smart card execution buffer 

30 

2The Script area - (includes the initialised data dictionary 
tables 

3The Uninitialised data dictionary table area 

35 

4The file/ batch area 
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getDataByte 

Returns the byte at the virtual address 

5 

uchar getDatalnt (of f set) 

Returns the two byte value at the virtul address specified. 
The format of the two byte value is always Low/High 
10 regardless of the byte ordering of the microprocessor. 

getScriptData 

void getScripff lata (uchar *buf f erMEMPTR offset, int size) 

15 

Transfers data from the buffer to the virtual address 
"offset" 

setScriptData 

20 

void setScripff lata (uchar *buf f er, OFFSETTYPE offset, int 
size) 

Either set external memory to NULL bytes or to a copy of a 
buffer buffer is the memory buffer in the standard memory 
25 area OR if NULL then the operation is like a memset 

add notes on offset type 

size is the number of bytes to store 



For customising the cardscript command set set 

Adding Function Primitives 

35 All function primitives have up to four parameters. Each 
Parameter is of either one or two bytes length. 



30 
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Numeric value parameters of values O. • 1 27 are one byte in 
lenght. Numeric values of greater lenght and in the general 
format, with a maximum value of 4999. 

5 

All other parameters are in the general format, sixteen bits 
High order first 

bit 15 set - numeric value all other 15 bits contain the 
value high nibble = 0x5 next three nibbles give string 
10 number, 

all other values high byte = table, low byte = field. 

Reference 
Index 
15 Glossary 
# 

"start bombO": <start-bomb> 

" time-tick {)" : in the script-driver for processing 1/10 
second time ticks 
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THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS: 

1. A device arranged to process messages for com- 
munications, comprising a virtual machine means including a 
message processor means which is arranged to process 

5 messages communicated to and/or to be communicated from the 
device, and message processor instruction means arranged to 
provide directions for operation of the message processor 
means • 

2. A device in accordance with claim 1, further 
10 comprising protocol processor means arranged to organise 

communications to and from the device, and protocol 
processor instruction means arranged to provide direc-tions 
for operation of the protocol processor means • 

3. A device in accordance with claim 1 or claim 2, 
15 wherein the device includes a micro .processor which runs in 

accordance with native software code, and the message 
processor means is implemented as the native software code 
of the micro processor. 

4. A device in accordance with claim 2, wherein the 
20 device includes a micro processor which runs in accordance 

with native software code and the protocol processor means 
is implemented as a native software code and the protocol 
processor means is implemented as a native software code of 
the micro processor. 

25 5. A device in accordance with any preceding claim, 

further comprising a function processor means arranged to 
control and select general operations of the device not 
controlled by the message processor means, and function 
processor instructions arranged to provide directions for 

30 operation of the function processor. 

6. A device in accordance with claim 5, wherein the 
device includes a micro processor which runs in accordance 
with native software code and the function processor means 
is implemented as native code of the micro processor. 

35 7. A device in accordance with any preceding claim, 

wherein the message processor means is arranged to assemble, 
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disassemble and compare messages, 

8. A device in accordance with claim 1, wherein the 
message instruction means includes a set of descriptions of 
message data. 

5 9, A device in accordance with any preceding claim, 

wherein the message processor instruction means is 
implemented in software defined by the message processor 
means, where the device includes a micro processor, and 
wherein the message instruction means do not require 
10 translation to the native software code of the micro 
processor . 

10. A device in accordance with any one of claims 2 to 

9, wherein the device includes a micro processor which runs 
in accordance with native software code and wherein the 

15 protocol instruction means are implemented in software 

defined by the protocol processor means, and do not require 
translation to the native code of the micro processor, 

11. A device in accordance with any one of claims 5 to 

10, wherein the device includes a micro processor which runs 
20 in accordance with a native software code, and wherein the 

function processor instruction means are implemented in 
software defined by the function processor means and do not 
require translation to the native code of the micro 
processor . 

25 12. A device in accordance with any preceding claim, 

including a hardware abstraction layer comprising a series 
of routines which provide a application program interface to 
exercise an operating system, BIOS or hardware drivers of 
the device. 

30 13. A device in accordance with any one of the 

preceding claims, wherein the device is a specialised 
network access device arranged for communicating over a 
network . 

14. A device in accordance with claim 13, the device 
35 being a remote payment terminal and the messages being 
messages relating to remote payment transactions. 
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15. A computer for developing message instructions for 
providing directions for operation of a message processor 
means in accordance with any one of the preceding claims, 
computer including a processing means arranged to receive 

5 data input by a user to build message instructions for the 
message processor means. 

16. A computer in accordance with claim 15, wherein 
the processing means is also arranged to receive data input 
by a user to build protocol instructions for a protocol 

10 instruction means of the device of any one of claims 2 to 



17. A computer including means for emulating the 
device of any one of claims 1 to 15, in order that the 
message instruction means developed for the device can be 

15 tested, 

18. A method of programming a device for processing 
communications, comprising the steps of loading a processing 
means of the device with a virtual machine means including a 
message processor means which is arranged to process 

20 messages communicated to and/or to ^be communicated from the 
device, and message processor instruction means arranged to 
provide directions for operation of the message processor 
means . 



25 the further step of loading the processor means of the 

device with a protocol processor means arranged to organise 
communications to and from the device, and protocol 
processor instructions arranged to provide directions for 
operation of the protocol processor means. 

30 20, A computer memory storing instructions for 

controlling a computing device to implement a virtual 
machine means comprising a message processor means arranged 
to processor messages communicated to and/or from the 
device . 

35 21. A computer readable memory in accordance with 

claim 20, further storing instructions for implementing 



15. 



19. 



A method in accordance with claim 18, comprising 
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message processor instruction means arranged to provide 
directions for operation of the message processor. 



5 



22 . A computer readable memory in accordance with 
claim 20 or claim 21, further storing instructions for 
implementing protocol processor means arranged to organise 



communications to and from the computing device. 

23, A computer readable memory in accordance with 
claim 22, further storing instructions for implementing 
protocol processor instructions arranged to provide 
10 directions for operation of the protocol processor means. 

2*4. A specialised network access computer, including a 
micro processor and a virtual machine means, the virtual 
machine means including instructions for running on a 
virtual micro processor and an interface enabling the micro 
15 processor to operate the virtual processor. 

25. A specialised network access computer in 
accordance with claim 25, being a remote payment terminal. 
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